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 > data. > >> We added support for byte[] to mutation in 1.5. Thinking back, we > should > >> 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 > happy. > > 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 > http://gravatar.com/ctubbsii >
