felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Leangen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-5332) Serializer
Date Wed, 21 Sep 2016 23:05:20 GMT

    [ 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)

Mime
View raw message