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

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?