Re: Oaf naming; the IID.

[Maciej Stachowiak <mjs eazel com>]

Snipping all but one bit of the doc quote

<michael@helixcode.com> writes:

> The only absolute requirement about these is that they uniquely
> identify an implementation - if you have to start taking md5sum's of
> /dev/urandom to accomplish this, so be it. Human readability is a
> "would be very nice" goal.

> [snip]
> 
> 	Ok; the new scheme is nice and oaf generaly is wonderful to
> my mind, but; I _hate_ the uuid concept.
> 
> 	The UUID is the random noise on the end of the AID. Let me
> disect my antipathy:
> 
> 	a) I see no good reason for a globally unique ID,

The ID needs to be globally unique. OAF will explode in ugly ways if
multiple implementations have the exact same implementation ID. It
will have absolutely no way to distinguish them, so one would
completely shadow the other in some arbitrary way.

> 	b) I see no enumerated rational behind it, including cases
> in which it might be used.

Cases in which what might be used? The UUID portion of the IID? It's
not meant to be specifically used on it's own. The IID string should
be considered an opaque token by apps and by OAF.

> 	c) a UUID is not a build date, hence there is no way of
> telling which of UUID you get is nicest if you have multiple oaf
> query matches.

You are not supposed to compare the UUIDs at all. The IID string is
random garbage as far as your app knows. It is just a unique ID. If
you want to define a "build date" attribute in OAF and compare on
that, you can do it, but for goodness sake, do not try to parse apart
the IID. The only thing you can realy on there is that it will be
prefixed by "OAFIID:"

> 	d) a UUID makes activation more complex, you can not
> manualy ask for a specific program, ie. I want OAFIID:my-program
> [ perhaps there is a good way of doing this, I havn't got into
>   oaf use yet ]

If you want a specific

> 	e) it needlessly introduces a small posibility of UUID
> clash, made worse but people cutting and pasting oafinfo files and
> not being bothered to generate a new number.

The numbers colliding is really not tragic if the names are different.

The main reason for the UUID is so that people who come up with the
same name and don't know about each other (and therefore are not cut &
pasting each other's code) will still have distinct names.

But in any case the UUID is no worse in this respect than any other
attempt at a unique ID. Either people will read the doc on how to
generate it and do so, or they will do something broken and
lose. That's life. You can't eliminate human error.

Anyway, it seems unlikely to me that people will do this, it has
worked reasonably OK in the world of Microsoft COM, where the UUID
must be written in one of 3 different formats dependign on context!

> 	f) this number is not unique across machines, nor is it
> useful for distributed components.

I don't understand why you make these claims, or what they
mean. `uuidgen' includes some bits unique to the host in the seed for
generating the UUID, and for remote activation you want to use an AID,
not an IID, which specifies IID + hostname + username + session name.

> 
> 	So; my alternative proposal is like this, we scrap the
> UUID totaly, and make up some sensible namespacing rules for
> the remaining part of the id. Perhaps the web address, or
> something, we also recover the use of ':' in this part.

Why is suign a colon bad? The IID is opaque. Nothing ought to be
parsing it anyway. I also don't like namespacing rules. uuids make
things work nicely without having to use central registration
authorities, or assuming anyone relevant has control over or access to
a useful DNS domain.

> 	Then we add either the former or both of these tags:
> 
> 	version	- this is the build version of the software.

If you want versioning, it should be a separate attribute, not part of
the unique ID. The UUID should only be changed when the component
should not be considered "the same" any more.
 
> 	This is useful for updating a running system with
> many users of each component; in as much that we can have a
> generic 'sort by version' for activation. 

Upgrading a component is no more likely to explode things from under
users than upgrading a garden-variety binary. Unix makes this work
reasonably.

> Perhaps that doesn't make sense in terms of the necessity to kill
> oafd on installing new oafinfo files; h

That's a bug, should be fixed soon.

> however, it would be nice to keep track of the oaf information for
> running factories separately, so they can be upgraded whilst
> running.

I don't see why this is a problem anyway.
 
>	This is also useful for checking conformance in
> development software, such that spurious version mismatch bug
> reports don't spring up.

I actually think it would suck if you had to change any hardcoded IIDs
in code that used a component every time a new release of the
component is made.

> 	install stamp - this is for the truly paranoid.
> 
> 	Perhaps your broken software only works with a specific
> magic build date of a component; match on this to make the
> world hate you, perhaps of use for development, could be
> automated via an oafinfo.in setup.

That would be completely evil. I refuse to condone that sort of thing.

> 	Of course, there is a really strong possibility that
> I have totally misunderstood the purpose behind the UUID, but
> I think it sets up an extremely dangerous alternative
> activation path 'by magic number', that I don't think we want
> to go down.

The UUID is just there to make the IID string unique. Really, one
should hardly ever want to ask for a specific component anyway. It's
far better to come up with an OAF query that asks for the specific
capabilities you want out of the component.

Please let me know if you are still unclear on this, and sorry for
taking so long to answer.

 - Maciej