String attributes feature (project review)

[Nico Williams]

On Tue, Sep 20, 2011 at 10:43 AM, Simo Sorce <simo at redhat.com> wrote:
> 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.

By using a domainname you get that for free via IDNA, while still
getting to use all-ASCII for the key itself.

>> 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 ...

Sure.  I don't care.  Either way will do for me.

>> >> 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.

Hmmm.  I may want to have at least the plugin name somewhere, so that
even on a system where the plugin has been removed I could find out
which keys to drop, or what they are.

So maybe the key naming convention should include the plugin name, not
just the vendor's.

Nico
--