[infinispan-dev] Implementing Hot Rod using Google Protocol Buffers?

[David M. Lloyd]

Protocol buffers won't work as a general serialization strategy - you'd 
only be able to transmit or receive objects which are defined in terms of 
protobufs (e.g. no Serializable objects).  The upside would be the ability 
to read objects from the cache which were written in other languages. 
However, is that a common usecase?

If you generate a pure binary protocol with opaque byte payloads, you can 
use any serialization strategy - protobufs, JBMAR, whatever - and leave it 
to the client to interpret the data.

I guess I'd think about what level of interoperability you're really 
looking for when you talk about cross-platform support, and what you're 
prepared to give up in exchange.

- DML

On 01/14/2010 09:49 AM, Galder Zamarreno wrote:
> Btw, in another thread, Trustin provided some interesting feedback:
>
> "I love the idea.  It will not yield the maximum performance comparing
> to the carefully handcraft one, but it's a matter of choice.  It's a
> great way to implement a protocol quickly, and you can replace it with a
> custom protocol later anyway when its performance is not satisfying.
>
> One minor disadvantage of protobuf is that you must have the whole
> message in memory when dealing with a non-blocking channel, no matter
> how large it is.  Therefore, you have to limit the length of the payload
> for each message.  It's not a big deal for most cases. However, if
> Infinispan needs to stream some large data, then you have to implement
> chunked encoding by yourself or define an alternative protocol."
>
> The first point it's probably something we can live with. In exchange of
> not the most performance solution, we get bigger potential audience
> reach thanks to being able to generate C++/Python client code. I might
> be naive but something I'm assuming is that a C++/Python generated
> client could talk to a Java based server. I mean, we're interested in
> people writing C++/Python clients, we could even create a Python one as
> an example/demo. But we're not in business to create C++/Python Hot Rod
> server code.
>
> The second point though it's more important and could be a show stopper.
> Infinispan is an all purpouse cache and we could certainly have clients
> wanting us to deal with situations like this.
>
> Thx Trustin for the feedback :)
>
> On 01/13/2010 12:30 PM, Galder Zamarreno wrote:
>> Hi,
>>
>> In a previous email, Bela suggested having a look at Google Protocol
>> Buffers for implementing Hot Rod.
>>
>> I had a brief look at Google Protocol Buffers and at first glance, the
>> most obvious advantage is that it abstract the lower level protocol
>> details and generate higher level code in different languages: Java,
>> C++, Python.
>>
>> Another thing I've noted is that it does seem to handle different
>> versions of the protocol in a transparent way, as indicated in "A bit of
>> history" section in
>> http://code.google.com/apis/protocolbuffers/docs/overview.html
>>
>> Once we're all happy with the protocol itself, I think it might be worth
>> doing a small prototype for example with a put operation and an a
>> cluster formation event and see how it works.
>>
>> What do people think? Anyone with Google Protocol Buffers experience
>> that could provide us with 1st hand advice?
>>
>> Cheers,
>