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

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,