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 _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 01/13/2010 03:32 PM, Manik Surtani wrote: > Are you referring to using protobufs as an alternate to the Marshalling framework for marshalling user data, or for implementing the commands, etc. of the protocol? The latter, as a way to implement the protocol itself using .proto files and generating the corresponding client/server classes. Clearly, if we're to use those generated classes, they'd be abstracting us from the lower level details and quite possible the marshalling itself.

> > > On 13 Jan 2010, at 11:30, 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 >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Manik Surtani > manik(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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,

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,