[katello-devel] Renaming of environments: summary

[Dmitri Dolguikh]

On 14/08/12 03:32 PM, Jan Pazdziora wrote:
> On Tue, Aug 14, 2012 at 03:13:37PM +0100, Dmitri Dolguikh wrote:
>>> That's clever, but is it really necessary? I'm not opposed to
>>> using it as a way to generate labels. But you'll still want to
>>> allow a user to enter their own label at creation time. They may
>>> not want the autogenerated one.
>> we are back to discussing discrimination against users not using
>> ascii-based character sets.
> Many parts of the computer systems have restrictions on the character
> sets.
>
>> In our case url of the resource is also its uri, and I'll put
>> emphasis on unique here. No human can generate random enough
>> information, and repeatedly asking the user to re-enter a bit of
>> information is bad ui too. Much easier is to generate the bit
>> automatically, leads to a better user interaction too.
> So the solution is to do an equivalent of
>
> 	iconv -f utf8 -t us-ascii//TRANSLIT
> 	
> plus change spaces and unprintable characters to underscores or
> dashes, possibly in lowercase, to come up with some default. Then
> check if the result is US-ASCII and if not, pre-fill some
> generated string (UUID, possibly) there instead. And let the user
> either accept the pre-filled default, or change it.
>
> You get the best of both worlds -- label resembling the name where
> possible, and something that the user cannot possibly remember but
> still generated for them in case the Kanji cannot be transliterated
> easily.
>
I kept forgetting another bit, which is uniqueness of the identifier we 
put in the url. The issue with human-generated one is, obviously, lack 
of randomness, and thus handling of things like removed-created with the 
same id.

I'm not sure why this is such a controversial point, but perhaps the 
fact that Katello is part of CloudForms which is going to have a rather 
large audience and therefore we can't quite predict how and by whom our 
API is going to be used, so it's important to maintain correctness would 
explain my points?

All I'm trying to do by these discussions is to maintain the principle 
of least surprise on the API level.
-d