David Leangen commented on FELIX-5332:

Hey [~bosschaert], it was not really my intent to own a new project 
(unfortunately, I don't really have the time or energy right now), so I just 
want to stop and think a bit about what we are doing before I dig myself in any 
deeper. :-)

The code I wrote is a very simplistic example, and needs a lot of work. It 
"works", in that I am able to do serialization with it, and I am now actually 
using it internally, but it's nowhere near ready for general use, I think.

The main point I was trying to make is that OSGi is creating a "Serialization" 
spec, does not seem to be giving consideration for what, I believe, is a 
critical element of serialization: the schema. Without a schema, complex data 
cannot be deserialized. The only reason this can work without a Schema object 
is because during deserialization, the application already knows which DTO 
object (including help from TypeReference) needs to be used. If that context is 
not there, or if the object is too "complex", then boom!

There are a few schema types out there. Here are a few:

 * xsd
 * [protobuf|https://developers.google.com/protocol-buffers/]
 * [Cap'n Proto|https://capnproto.org/]

I am sure there are others. (I think the last one is really neat, as it also 
explicitly deals with generics.)

The DTO in OSGi *is* the data schema. If it can not be properly serialized / 
deserialized, then there is a serious problem, IMHO. I was trying to point out 
this problem, but it is turning out to be much more involved than I had 
originally imagined.

The above listed solutions are "complete", but they also drag in a log of 
baggage. It would seem that the last 2 even require a native compiler to be 
installed. They all seem to work "offline" or during the build, rather than at 
runtime. It would be awesome to have a language agnostic schema, which could be 
converted into any of these formats. The DTO has that potential. It would be 
extremely powerful, combined with the Converter and "Serializer".

I think my little experiment here can be considered both a success and a 
failure. It is a success in that I was able to accomplish the job of 
serializing somewhat complex data (complex enough that it could not be done 
without a schema) by way of this simple prototype, but it was a failure in that 
we have not yet found a good way to integrate it, and I don't think I've yet 
convinced anybody of its necessity.

I think we need to sit back and think of something more convincing, perhaps, 
before continuing to pursue my experiment.


BTW, I am having a bit of trouble with naming it a "Serializer" if it cannot 
completely do the job... Codec actually seemed more appropriate. Just sayin'. 

> Serializer
> ----------
>                 Key: FELIX-5332
>                 URL: https://issues.apache.org/jira/browse/FELIX-5332
>             Project: Felix
>          Issue Type: New Feature
>          Components: Converter
>            Reporter: David Leangen
>            Assignee: David Bosschaert
>         Attachments: patch.diff
> Test case and a bit of code to show how a Serializer could work.
> To work as a Serializer, the type information needs to be embedded into the 
> output.

This message was sent by Atlassian JIRA

Reply via email to