Am Mittwoch, 21.05.03 um 15:39 Uhr schrieb Lex Spoon:

> "Andreas Raab" <andreas.raab at gmx.de> wrote:
>
>> You are missing the entire point of my message, namely that this is 
>> NOT an
>> 'either or' situation. In other words:
>>
>>> Suppose I email someone about a package -- should I
>>> use the name or the UUID?
>>
>> I don't care the least bit! User either one. That's the whole point.
>
> In some of the cases, I'd be compeled to use the UUID.  Specifically, 
> if
> I think my email will be archived and looked at later on, then I need 
> to
> use the UUID.  That's a pity, and a names-only scheme avoids this
> situation.  People won't change package names very much if those names
> are primary keys being widely used.

I share that sentiment. Is there any compelling reason that we have to 
use UUIDs?

I find the line of argument in the Zeroconf standard very convincing. 
They chose to use readable names instead of a dual ID/name scheme. It 
has various implications, including simplicity and, ultimately, 
elegance ;-)

    "Some service discovery protocols decouple the true service 
identifier
    from the name presented to the user. The true service identifier used
    by the protocol is an opaque unique id, often represented using a
    long string of hexadecimal digits, and should never be seen by the
    typical user. The name presented to the user is merely one of the
    ephemeral attributes attached to this opaque identifier.
    [...]
    In summary: The user-visible name is the primary identifier for a
    service."

See http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt, in 
particular section 4.4 "What You See Is What You Get". Now that has 
nothing to do with package names, but I think the analogy still holds.

-- Bert