Adding quotes would be a little heavyweight for my purposes, but that sounds like a good idea.
I don't think that letting in . and / characters would have a significant negative effect on the grammar flexibility, especially since the resulting expressiveness would be less than URI's, which have pretty reduced expressivity themselves, but other people might have some use cases in mind where this could be a problem. On a separate but related note, the docs seem to say : isn't valid (see http://accumulo.apache.org/1.4/apidocs/org/apache/accumulo/core/security/ColumnVisibility.html#ColumnVisibility(byte[])) but the code does (see https://github.com/apache/accumulo/blob/trunk/core/src/main/java/org/apache/accumulo/core/security/Authorizations.java) on line 62 On Wed, Jul 11, 2012 at 4:56 PM, Keith Turner <[email protected]> wrote: > Ed, > > Seems like a good, standard way to avoid name collisions. I do not > think 1.4 is right place, 1.4.X release should mainly be bug fixes. > > At some point we had a detailed discussion about allowing more > characters in the labels. The con is that it takes away from future > flexibility of the language. I was advocating for supporting quoting > and escaping labels instead taking away reserved chars. So support > expressions like : 'vis://A/B' & 'vis://A/C' where you can put any > char between the quotes as long as quotes are properly escaped. > There are a few standard escaping mechanisms we could choose from. > > Adding quoting should be done in a backwards compatible way. > > Keith > > On Wed, Jul 11, 2012 at 3:59 PM, Ed Kohlwey <[email protected]> wrote: > > It would be nice to support hierarchical visibility strings, so that an > > application could use a URI to delegate control of a certain set of > > visibilities to a particular organization that you'd like to have control > > those visibilities. Ex: visibility://some.org/some-dept/visibility > > > > You COULD use the existing characters to construct a hierarchical scheme, > > but it would be more terse than a restricted URI and you'd have to get > > pretty creative with your encoding. > > > > It looks like you could add slash and period to the allowed characters > > pretty easily by adding a new statement in Authorizations.class around > line > > 62. > > > > Any thoughts on pros/cons to doing so? Any interest in doing this in a > 1.4 > > release? >
