Re: [smila-dev] ipc (de)serialization vs. generic handling

[Thomas Menzel <tmenzel@xxxxxxx>]

Also comments inline

Thomas Menzel @ brox IT-Solutions GmbH

>-----Original Message-----
>From: smila-dev-bounces@xxxxxxxxxxx 
>[mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of Jürgen Schumacher
>Sent: Donnerstag, 24. November 2011 09:09
>To: Smila project developer mailing list
>Subject: 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.

Well, yes. But AFAICS this JsonReqHandler doesn’t do anything JSON specific anymore after I'm thru with it ;) and hence I would rename it to smth. like IpcRequestHandler or IpcSingleRecordRequestHandler.
If one still needs JSON specific stuff, then a new JsonRequestHandler  class could be reintroduced and inserted in the class hierarchy.

>
>> 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 had been thinking about this too but, here are the reasons I didn’t suggest it (though I should have written about this)
- it makes it harder to spec this in a browser/GET setting
- I'm not sure if we should define unstandardized mime types, or if that is an OK practice. If we have these then these should be the ones to register the impls. under. If we go this way then we should, include optionally the version of the XML as well, like so: application/vnd.smila.record+xml+.2.0. If the version isn’t given then the current one is the default.

>
>> 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.

not quite understanding this answer... Might be b/c i dont know really how the IPC reader works. 
with 'SMILA XML' you mean our XML serialization format version 2.0? and with 'generic XML' mean you mean another XML representation of a record (that doesn’t exist)? 
OR if not, I could only think of this meaning, that the IPC reader doesnt support nested Maps/sequences reecords?    

Note: I'm understanding IPC such that it means "Inter Process Communication" and is then an abstract term to denote diff. serialization formats, that can be arbitrarily structured/capable internally. As consequence XML should be included as part of. But if this not what IPC is all about and has a diff. scope/intention I might be "barking up the wrong tree"/ "on the wrong track"?

>
>> 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.
>

OK thx
Cheers,
Juergen.
_______________________________________________
smila-dev mailing list
smila-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/smila-dev


http://www.Taglocity.com Tags: smila, spec