String attributes feature (project review)

[Simo Sorce]

On Tue, 2011-09-20 at 10:31 -0500, Nico Williams wrote:
> On Tue, Sep 20, 2011 at 10:17 AM, Simo Sorce <simo at redhat.com> wrote:
> > On Tue, 2011-09-20 at 09:28 -0500, Nico Williams wrote:
> >> A few comments:
> >>
> >> a) the key should be all US-ASCII;
> >
> > What's the point of limiting it to US-ASCII when UTF-8 is a standard and
> > allows proper internationalization ?
> 
> These sorts of keys don't need to be internationalized.
> 
> Internationalizing lookup keys means handling normalization.  That
> seems way too heavyweight for the purpose of this extension.

Given you are talking about having a vendor prefix/suffix I would like
to be able to use a company name in its original form.

If my company name is Järvi Oy, I'd like to be able to to have
'järvi_otp_name' as the name of the option instead of distorting the
name.

> >> b) the key namespace needs more guidance/definition (e.g.,
> >> feature at domainname, a la SSHv2);
> >
> > I would say that a vendor prefix makes for a better name space (and let
> > displaying code to more easily order alphabetically and get all vendor
> > related keys together with ease).
> > Something like:
> >
> > mit_otp_name = value
> > rh_otp_name = value
> > rsa_otp_name = value
> > etc...
> 
> I don't care what it looks like, as long as we have a naming
> convention that helps prevent collisions.
> 
> If you want the keys to sort nicely, though, you should want a vendor
> *suffix* :)

I think it is more important to group options by vendor, which is a
simple alphabetical ordering if you use a prefix.
But whatever ...

> >> c) should any type information be included for the data part?
> >
> > type is "string" so far ?
> 
> Sure, but the string's form is given by the kind of data being stored
> in it.  A type indicator would be completely superfluous, I agree, but
> it might help users (think of a URL to documentation of the given
> key's value format).

Sounds like just too much. In general the value is a simple string, in
those cases where it is not you have to document yourself to understand
what it is anyways.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York