Continuing discussion of oaf ...



Hi Mathieu,

On 19 Nov 2000, Mathieu Lacage wrote:
> 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.

        Thanks for this.

>         - 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.

        Yes.

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

        Well; these would be for the fully free bits of software, the rest
would use the standard omg rules folling the DNS style allocation scheme.
When I say 'control', I mean we should try to advise people as to sensible
names to use.

> - 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.

        It scales as easily as binary names for executables, in fact
rather better because people can use org/suckmythumb/fish ( which they
happen to have registered ).

> - 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...

        Dude; we use the GNOME/ / Bonobo/ namespaces only for GNOME
packages, if you don't want to be part of either of these you talk to the
omg, or use their standard namespacing guidelines. No problem.

        Furthermore, if you read my mail again, you will notice that I
suggested that we leave the optional:

123-3214-3-4524-365-24-23-4-3246-345-635-67-3-324523-45-324-23-6-35635-565-3145-23-1-23-1-34-7-6579-6789-56-785-6787-56-3-6-3245-34-3-4578-56-762-346-$

        on the end of the string for people who are unreasonably paranoid
that they will not be able to sensibly organise their namespace, or for  
people without a namespace.

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

        I think you are also missing the point that many components ( and
this will definately increase as we solve the scriptability issues and
start implementing components in non-[FULLY!]-compiled languages ) that
each component will implement its own interfaces. This will _Neccessarily_
lead to the need to namespace these things.
 
> UUIDs are an easy solution of this problem. (although, as we have
> discussed it, not the most perfect one)

        UUID's are a short term hack, that relies on the assumption that
most people will not want to implement any new interfaces, which is just
silly. True, currently it is too difficult to do so, but I expect this to
become easier through a several pronged strategy.

        So I ask you to re-consider, my suggestion has the best of both
worlds; an easy to type, and _Check_ by eye, naming scheme, with the
option of adding a huge number to the end if you do not believe you can
sensibly partition your space. Eg. perhaps gnome-core's applets might want
to make this the default usage.

        Regards,

                Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]