String attributes feature (project review)
nico at cryptonector.com
Tue Sep 20 11:58:24 EDT 2011
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
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.
More information about the krbdev