It seems like the only heavy part of the client would be the zookeeper interactions (forgive my
ignorance if I'm wrong). Other than zookeeper only a basic understanding of regions need to be
understood. So if the zookeeper interactions could be removed and pushed somewhere else in the
stack that could make the client much thinner.
I understand not maintaining multiple clients nor do I think the project should maintain another
client right now. However now seems like the time to plan for new clients in other languages. When
will be the next time the client / server protocol is changed? I'm guessing most people would say
hopefully never again. IMHO since you are redoing the communication why not improve the protocol to
allow for a leaner the client. A leaner client would be more likely to work across major hbase
changes, would be easier to maintain, would hide implementation details and could have less
dependencies. One of the reasons the client doesn't do well across major changes is because of how
heavy it is. Even if the client is never implemented in another language a thinner client would seem
to be an improvement.
What I'm suggesting may not be possible but it seems like it is worth keeping in mind through the
design and implementation process.
~Jeff
On 2/16/2012 4:09 PM, Todd Lipcon wrote:
On Thu, Feb 16, 2012 at 3:04 PM, Jeff Whiting<[email protected]> wrote:
Will this allow for hbase clients in other languages? It seems that if pb
are being used then any language pb supports could have a first class client
and not have to use a separate (and not super maintained) thrift server. You
would want to keep the client to be light though if it were to be ported to
other languages.
IMHO it seems that if we are going to the work of redoing the client
communications we should be considering other languages. It seems like
having first class clients in various languages could only increase hbase
adoption which would be a good thing :-) I would really like to see hbase
be more usable from other languages besides java.
The issue is that HBase's client is necessarily not thin. It requires
a lot of knowledge of HBase itself -- so certainly moving to PB would
get us one step closer, but it would still be quite a bit of work to
write a new client in another language. Certainly if someone comes
along with one, that would be nice, but I don't think we should take
it upon the project (yet) to maintain any other language clients.
-Todd
On 2/13/2012 12:01 PM, Jimmy Xiang wrote:
Hello,
As HBase installation base is getting bigger, we are ready to work on the
wire compatibility issue.
The goal is to make HBase easier for operators to upgrade, while it is
also easier for developers to
enhance, re-architect if necessary.
The attached is a proposal we came up. We'd like to start with two
phases:
Phase 1: Compatibility between client applications and HBase clusters
Phase 2: HBase cluster rolling upgrade within same major version
Could you please review?
Thanks,
Jimmy
--
Jeff Whiting
Qualtrics Senior Software Engineer
[email protected]
--
Jeff Whiting
Qualtrics Senior Software Engineer
[email protected]
