Re: [infinispan-dev] Findings of ISPN-508 - Portable serialization marshaller
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev