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

[Galder Zamarreno]

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?
>>

-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache