[infinispan-dev] Findings of ISPN-508 - Portable serialization marshaller

[Galder Zamarreño]

I've updated the spreadsheet with a comment about support for old custom objects: http://spreadsheets.google.com/pub?key=0Ag5RGdzR_GsldEJkUEExX2JPTHdsSF93MkdENkZOUmc&hl=en&output=html

One important note about 3. From a configuration perspective, this is very similar to https://jira.jboss.org/browse/ISPN-244. The major difference is the underlying marshaller used. Whereas for 244, the aim is for java specific JBoss Marshaliing to do the hard work, in this case the aim is for a language portable library to do the hard work, i.e. Protobufs.

On Jul 22, 2010, at 11:47 AM, Galder Zamarreño wrote:

> Ok, dealing with simple types/collections is clear. We delegate to the corresponding library and that's it.
> 
> As far as custom types that are controlled by user, so I've gone and compared 3 different methods to deal with them:
> 
> Option 1. User/client code generates the byte[] from a precompiled class. Code example: http://pastebin.com/iqX9rVqV
> 
> Option 2. User/client gives us the Pojo and our marshaller converts it into a byte[] with the help of the precompiled class methods. Code example: http://pastebin.com/FTTjcfR4
> 
> Option 3. User/client gives us the Pojo and our marshaller converts it into a byte using client provided serializer/deserializer impl that relies on portable simple type marshaller. I don't have a code example but it'd be very similar to option 2 with the following changes: At startup, ids and class names would be mapped from a given configuration. At writing time, the id would be written and the rest would be delegated to user provided impl. At reading time, once the id has been determined, the class would be instantiated and it would delegate to it the rest of the reading part.
> 
> With this in mind, I've created a spreadsheet comparing them based on different factors: http://spreadsheets.google.com/pub?key=0Ag5RGdzR_GsldEJkUEExX2JPTHdsSF93MkdENkZOUmc&hl=en&output=html
> 
> I'm leaning towards 1 for its simplicity (less code and less configuration in spite of required precompilation) and performance (no extra bytes, no reflection or class loading).
> 
> Thoughts?
> 
> On Jul 22, 2010, at 3:11 AM, Mircea Markus wrote:
> 
>> 
>> On 21 Jul 2010, at 14:40, Emmanuel Bernard wrote:
>> 
>>> 
>>> On 21 juil. 2010, at 15:23, Galder Zamarreño wrote:
>>>> I'm not so sure I understand the type of solution that would work for #2 though. A java client can generate a payload that can be read by the java server. So, a non-portable solution could just use normal serialization to take an example. However, what would you do with a python client that sends a custom object? How is the java server gonna transform that into a java class?  
>>> 
>>> You'd be screwed but that's my point it's not useful that often.
>>> 
>>> But when it's useful, I kinda like the approach taken by Coherence: ie a special (de)serializer implementation for a given conceptual type: the user develop the native type for each of its client language + the serializer / deserializer for this type.
>> they also need  the xml describing the object (their version of .proto). Compared with Coherenece's POF, I think using ProtoBuf is better as you only need to define metadata: then types + serializer are generated for you using protoc. Less effort.
>> Where they might be better is if their core is aware of POF definition and it can index properties of portable objects - which would be cool.
>>> In your example and with this method, you would get a python code reading the stack of serialized primitive types and populate the equivalent python type.
>> I think an equivalent solution can be based on ProtoBuf. 
>>> We're back to the case #1 in essence where the stored data is really an intermediary format and the conversion to the final object is handled by manual code.
>>> 
>>> Note that they don't support circularity, which indeed is a bitch.
>> +1. Not sure protobuf supports it either
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache