hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Chanan <gcha...@cloudera.com>
Subject Re: HBase wire compatibility
Date Thu, 16 Feb 2012 22:58:25 GMT
Given the +1s, let's do the meetup at:

Tuesday Feb 21st @ 1:00 PM - 3:00 PM
Cloudera Palo Alto
210 Portage Ave,
Palo Alto, CA 94306
Let me know if you have any questions about getting here, etc.

@Ted: I prefer 1 pm because people already agreed to it and it gives us
more time if people want to stay later for more discussion or coding.  You
are certainly welcome to join us late.

Greg

On Thu, Feb 16, 2012 at 2:41 PM, Jacques <whshub@gmail.com> wrote:

> Fair enough.  That's why I mentioned ByteString more than anything else.
>  If the new RPC will always convert client api/application values into
> ByteStrings and my application is always storing protobuf keys and protobuf
> objects, it'd be nice if I could just hand you a ByteString as the value
> for each of these rather than converting them back to byte[] and then
> having you convert them again.
>
> thanks,
> Jacques
>
> On Thu, Feb 16, 2012 at 2:33 PM, Todd Lipcon <todd@cloudera.com> wrote:
>
> > On Thu, Feb 16, 2012 at 2:27 PM, Jacques <whshub@gmail.com> wrote:
> > > Or at a minimum, it would be nice that if
> > > we wanted to get access to the lower level pb objects, that
> modifications
> > > to HTable and/or supporting classes wouldn't be super complicated.
> >
> > It's less a matter of complexity, and more a matter of not wanting to
> > expose the implementation details as part of the API. It really
> > restricts us when we do this -- for example, KeyValue is used in the
> > underlying storage all the way up through the client API, which means
> > it's verify difficult for us to do something like switch to an
> > off-heap storage for cell data, for example.
> >
> > That said, the request for an easy way to build convenience APIs with
> > low numbers of copies makes sense
> >
> > -Todd
> > --
> > Todd Lipcon
> > Software Engineer, Cloudera
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message