[infinispan-dev] HotRod: Digging further into the encoding of data

[Manik Surtani]

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 at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org