[
https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15511473#comment-15511473
]
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.
wdyt?
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
(v6.3.4#6332)
