summary of the previous thread on oaf IIDs (as I remember it)

[Mathieu Lacage <mathieu eazel com>]

hi all,

Ok, I do not really care what convention is used for IIDs. I just want it 
to work well so here is what I recall on the previous discussion on this topic.
This might help us to make a better choice.

        - OAF has a requirement: IIDs HAVE to be unique across all the components
        of the known universe. UUIDs guaranty this with a _high_ probablity.

        - UUIDs are difficult to type and remmeber.

        - namespacing rules to build IIDs allow more easy to remmeber and type IIDs.
        This also guaranties a _high_ probability of uniqueness provided you control
        the namespace and its allocation.

As I understand, folowing michael's proposal, we would control the GNOME/BONOBO namespace.


So, here are the reasons why I think even with the control of the namespace, dropping
UUIDs is a bad idea.

- using a namespace means that you have to be able to assign parts of it to people as
they request it. This has to centralized and imposes a certain load of administration.
While this is still feasible now with the small amount of components around, I do not
think it will scale very easily.

- if I am random HaXXor X and I want to hack my own smallish component, I have to request 
for a namespace or hope that the name I pick up randomnly will never be used by anyone.
The advantage of UUIDs in that case is that I do not need to refer to a central authority
because I am prety sure the UUID I will use will be unique. Aslo, I might be hacking on 
something completely unrelated to GNOME in which case it would not make much sense to ask
for my own namespace in the GNOME one and who could I ask who would waranty the uniqueness
of my namespace ? Namespaces solve the problem only for the GNOME packages...

So, the problem, to summarize is centralizaion vs distribution of uniqueness.

UUIDs are an easy solution of this problem. (although, as we have discussed it, not the
most perfect one)

I hope the above makes sense.

regards,
Mathieu

-- 
Mathieu Lacage <mathieu eazel com>