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

[Emmanuel Bernard]

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.
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.
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.