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

[Galder Zamarreno]

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,

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