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

And another question: With regards to individual fields in Map/Array, according to your wiki, each field then only contains the size of the field and the field. So, in a map of booleans, each field would be represented as: 0x01 and 0x01/0x00 with 1st being the size and 2nd being the actual value. Correct?

On 01/12/2010 04:46 PM, Galder Zamarreno wrote: > 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? >>