[katello-devel] Renaming of environments: summary

[Dmitri Dolguikh]

On 14/08/12 04:42 PM, Justin Sherrill wrote:
> 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?
We are going to have a problem distinguishing between a deleted 
environment and a just created environment with the same label then. 
This is a problem because the url's are out of our hands once we 
generate a given resource. Since we can't control how a given url is 
being used, and can't notify the user that it has changed, we need to 
make sure that either points to the original resource, or returns a 404.

We are part of CloudForms, I don't think we can predict how our API is 
going to be used. As an example look at what Heroku did with Amazon WS, 
and how people use Heroku.

In this light: some piece of code on the client side uses API to 
enumerate available environments. Some time passes. Some admin deletes 
one of the environments. Some time passes. Some admin creates an 
environment with the same label. The original client re-syncs 
environments. Instead of detecting a deleted environment, it sees that 
the environment is there and alive. The resulting issues are going to be 
a living hell to debug.

We could keep track of labels that have been used in a given Katello 
install. But that would mean some sort of synchronization between 
individual instances of Katello in a given install, something I'd rather 
avoid if possible.

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