accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-743) Authorization constructors are pretty wonky - String research?
Date Wed, 23 Apr 2014 16:53:16 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978438#comment-13978438
] 

Christopher Tubbs commented on ACCUMULO-743:
--------------------------------------------

To be clear, the design goals of Authorizations is that they be human-readable. So, everything
should be Strings. The constructors which take bytes are there for implementation details
or marshaling/serialization purposes. I mention this not because I disagree that things are
"wonky"... they certainly are... but because I want any improvements to keep this design principle
in mind.

> Authorization constructors are pretty wonky - String research?
> --------------------------------------------------------------
>
>                 Key: ACCUMULO-743
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-743
>             Project: Accumulo
>          Issue Type: Sub-task
>          Components: client
>            Reporter: John Vines
>
> The various constructors for Authorizations are somewhat all over the place. There is
only one which uses Strings (most convenient for the user) but it only accepts them via variable
args.
> The rest are in some form of bytes. One is a comma seperated byte array, one is a List
of ByteBuffers, and then there is another which is a Collection of byte[].
> We make extensive use of bytes instead of Strings due to encoding concerns. I would like
to see a bit more consistency in the constructors for Authorizations. Because right now we
sort of have a half assed approach of being safe by using Bytes, but then having Strings (as
var args) for usability. I think we need to come up with a definite yes or no on Strings,
and then provide appropriate methods for dealing with them.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message