On 18 Feb 2010, at 19:46, Alex Kluge wrote:
This means that they byte representation has to contain the object type, and if it is a
more complex
type, it's size. We can use a custom encoding, or we can use serialization, there
just isn't much else.
Serialization struck me as a little heavy weight, and our application has a lot of
primitive values, and
arrays of primitive values, and a few maps that get cached, so this encoding scheme is
working well
for us.
Then we can make the marshaller pluggable again (on the client side). This should not be
baked into the protocol. The protocol needs to be *very simple* for a number of reasons
(ease of maintenance, debugging, robustness, extensibility, ease of writing more clients
for other platforms, etc), and as such, the protocol should *just* deal with binary data,
and not worry about encoding.
Now how the client converts an object to a byte array and vice versa, that's up to the
client. The default impl we should ship with would use simple Serialization. Or perhaps
the Infinispan Marshaller impl, as this effectively uses Serialization for custom types,
and is smarter about primitives, Strings and collections. And if this is pluggable, then
you can specify whichever mechanism you want for this layer, e.g., XStream, a JSON
encoder, Google protobufs, Python pickle, whatever.
And then you won't have the problem of the server-side attempting to deserialize
something it wouldn't be able to.
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org