Ed Kohlwey 2013-07-05, 11:59
Josh Elser 2013-07-05, 12:39
Josh Elser 2013-07-05, 13:50
Ed Kohlwey 2013-07-05, 14:38
Keith Turner 2013-07-05, 17:13
Ed Kohlwey 2013-07-05, 14:33
Keith Turner 2013-07-05, 16:40
Josh Elser 2013-07-05, 17:07
Ed Kohlwey 2013-07-05, 17:31
Ed Kohlwey 2013-07-05, 17:27
Christopher 2013-07-05, 20:29
-Re: Generic Supertypes/Pluggable Client
Ed Kohlwey 2013-07-08, 14:22
What do you think about making something like a SecurityLabelStream or
similar? That does an depth first traversal of the label expression?
On Fri, Jul 5, 2013 at 4:29 PM, Christopher <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 5, 2013 at 1:27 PM, Ed Kohlwey <[EMAIL PROTECTED]> wrote:
> >> It would be very nice if the types you mentioned were more consistent
> >> across the API. Personally I would like to see byte and ByteSequence
> >> fully supported across all of the APIs related to reading and writing
> >> We added support for byte to mutation in 1.5. Thinking back, we
> >> have added support for ByteSequence too.
> > +1. If we make everything tie back to ByteSequence and make the
> > serialization/deserialization logic pluggable, then everyone will be
> > Do you have any ideas based on the sketch I included that would help make
> > this better for all types, not just byte?
> I'd be very cautious about making *everything* tie back to
> ByteSequence. Some things, are more constrained than bytes... such as
> Column Visibilities, which we assume are human-readable strings, and
> it'd be more appropriate to tie it back to CharSequence than
> ByteSequence in the API, even though internally it's just bytes. The
> bytes we store for this should really be UTF8-encoded characters.
> Table names are another place where we use Text sometimes in the API
> to refer to something containing a String/CharSequence and cannot be
> arbitrary bytes... though I don't think your proposal affects that
> part of the API as much.
> Christopher L Tubbs II
Christopher 2013-07-08, 16:28
devramiyer1@... 2013-07-06, 04:11