Re: [infinispan-dev] Enconding of data WAS Re: Hot Rod - pt3

Hi Alex, Wrt the discussion below about encoding data, I wanted to know what exactly COMPRESSED type meant in your wiki, or what exactly it represents. Also, I wanted to know what bits you send when the object sent accross is an instance of java.lang.Long. Apart from marking LONG, do you also marked as SERIALIZED? Or do you just use SERIALIZED for user-specific classes? Cheers, On 01/05/2010 10:52 AM, Galder Zamarreno wrote: > > > On 01/04/2010 10:44 PM, Alex Kluge wrote: >>>> </snip> > >> >>>> - What happens if the key or the value is not text? I have a way of >>>> representing the data to allow for a wide variety of data types, >>>> even allowing for arrays or maps. This will make the protocol more >>>> complex, but the assumption that the data is a string is rather >>>> limiting. This is already sketched out in the wiki. > > Hmmmmm, I don't think I've made any assumptions in the wiki that keys or > values are Strings unless I've made a mistake somewhere (maybe in the > example where I've used a particular encoding for Strings?). My thoughts > around this was that I was gonna treat them both as byte[]... > >>> >>> </snip> >> >> The idea is to prefix each data block with a data type. This is a >> lightweight binary protocol, so a full fledged mime type would be >> overkill. There is a discussion and example in the Encoding Data >> section of this page: >> >> http://community.jboss.org/wiki/RemoteCacheInteractions >> >> Data types are limited to things like integer, byte, string, boolean, etc. >> Or, if it isn't a recognised type, the native platform serialisation is >> used. There can be arrays of these types, or maps as well. >> >> Each data type is represented by a bit, and they can be used in >> combinations. An array of bytes would have the array, byte and >> primitive bits set. The set of recognised data types can of course be >> expanded. > > ... but that looks rather useful (at least based on the cached version > of that wiki that Google shows ;) - no wiki access right now :( ), > particularly the way you can combine different bytes to create composed > types. I don't see a problem with including this in Hot Rod. > > I suppose you included type length into length field so that in the > future you can support other types and possibly longer type fields? >