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

[Galder Zamarreno]

On 01/14/2010 04:49 PM, 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.

p.s. protobuf makes a note of this in:
http://code.google.com/apis/protocolbuffers/docs/techniques.html#large-data

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

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