[katello-devel] Renaming of environments: summary

Justin Sherrill jsherril at redhat.com
Tue Aug 14 15:42:16 UTC 2012


On 08/14/2012 10:59 AM, Dmitri Dolguikh wrote:
> 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 an issue.  If the user is creating an 
environment in an org and the label already exists, throw an error, 
otherwise don't?

> 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
>
>
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel




More information about the katello-devel mailing list