I dont think protobuf is winning the war out there, it's either thrift or avro at this point. Protobuf just isn't an bazzar open-source type project, and it's non-Java/C++/python support isn't 1st class, plus no RPC.
As for the past RPC, it's all well to complain that we didn't spend more time making it more compatible, but in a world where evolving features in an early platform is more important than keeping backwards compatibility (how many hbase 18 jars want to talk to a modern cluster? Like none.), I am confident we did the right choice. Moving forward I think the goal should NOT be to maintain the current system compatible at all costs, but to look at things like avro and thrift, make a calculated engineering tradeoff and get ourselves on to a extendable platform, even if there is a flag day. We aren't out of the woods yet, but eventually we will be. -ryan On Fri, Mar 4, 2011 at 8:50 PM, M. C. Srivas <mcsri...@gmail.com> wrote: > Google's protobufs make this problem more palatable with optional params. Of > course, you will have to break versions once more .... > > On Fri, Mar 4, 2011 at 10:04 AM, Stack <st...@duboce.net> wrote: > >> On Fri, Mar 4, 2011 at 12:24 AM, tsuna <tsuna...@gmail.com> wrote: >> > In practice, bear in mind that HBase has a bad track record of >> > breaking backward compatibility between virtually every release (even >> > minor ones), although they often bump the protocol version number even >> > though there are no client-visible API changes (e.g. because only some >> > internal APIs used by the master or other administrative APIs >> > irrelevant for the client changed). >> >> At Benoit's suggestion, we've changed the way we version Interfaces; >> rather than a global version for all, we now version each Interface >> separately. More to come... >> St.Ack >> >
