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

[Mircea Markus]

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