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

[Galder Zamarreno]

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

Well, this would be more like an array actually.

By the way, in a Map, how do you send key/value pairs? I suppose 
[key][value][key][value]? And how do you provide type of key vs type of 
value?

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