[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [smila-dev] ipc (de)serialization vs. generic handling
|
Hi,
Comments inline...
> From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of Thomas Menzel
> Sent: Thursday, November 24, 2011 8:10 AM
> To: SMILA DEV
> Subject: [smila-dev] ipc (de)serialization vs. generic handling
>
> Hi folks,
>
> Some time ago I discussed with igor that it would be nice to support all serialization formats equally on the > handlers and he agreed. I was looking into this and how this could be done. The initial idea I had, was to
> refactor the JsonRequestHandler such that it would generically convert any incoming stream to a record for
> internal usage from any of our serialization formats, i.e. adding XML!
Yes, of course, that would be nice (:
But maybe we should not refactor the JsonRequestHandler for this, but a new base handler class to do this, and migrate existing handlers to these.
> The idea was to either
> - auto detect the format (could be done by investigating the 1st byte in the stream. But this might lead to
> problems when we allow to extend the formats, see below) OR
> - to have a URL param such as inputFormat and then go from there.
> Also I was thinking that it would be neat to be able to define the output format if desired with the default > being the same as the inputFormat.
The correct way to do this in ReST APIs would be to use HTTP header settings:
- "Content-Type:" to describe the format (as a mimetype + encoding) of the request body.
- "Accept:" to specify which response formats (again as a mimetype) the client can read.
And usually the mimetype would not only be something generic like "text/xml" (which would be
just any XML) but "application/vnd.smila.record+xml" to denote that the XML is a SMILA record.
> I have been looking at the IPC code and don’t think it is well factored such that
> - what I want to do is an easy job/generic
> - it is extendable for other future formats
Yes, because the IPC code is not meant to be generic, but only to support JSON/BON like formats because it depends on specified sequences of parse events. I suppose it would possible to add an XML implementation to handle the standard SMILA XML record form (because that's basically the same sequence of START_MAP, START_SEQ, some values, END_MAPPING, etc.), but not to process any generic XML format and map it to records.
> What I would have supposed/liked to see is a generic interface named smth. like IpcStreamReader or
> IpcRecordReader (I know classes exist for these names already but they are not generic) that allows to impl
> the method Record read(InputStream | byte[]| String) and be done with it. The same ideas apply for writing
> records. The specific impl to support XML, JSON, BON could come (for now) from a simple un-configurable
> factory/registry.
> Ultimately I think I would be neat to allow also 3rd party formats. To support this the IpcXXXReader impls
> for the specific format could be requested from a OSGi ServiceFactory by a name/ID where the impls could
> register themselves against.
Yes, but it would be a more generic concept than the IPC stuff. A "generic request handler" could choose (de)serializers based on the "Content-Type:" and "Accept:" headers if (de)serializer services would be registered with a property describing the mime type they can parse/produce.
> Since I have seen that there has been some refactoring and extension in the IPC area I was wondering if there > are plans in that direction or not.
There are no fixed plans, as we (@attensity) currently don't need this, but there is also no reason against it. (; We should definitely have this on the roadmap as a ReST API should do proper mimetype handling.
Cheers,
Juergen.
