Oaf naming; the IID.

[<michael helixcode com>]

Ok;

	This is I think a really important issue to get right before
we go too much further; Currently the following holds:

[snip oaf/docs/id-format.txt]

	The Implementation ID (IID)

These are strings that uniquely identify an implementation. The only
restrictions on these are that they be ASCII, begin with "OAFIID:",
and not contain the comma (','), square bracket ('[]'), or forward
slash ('/') characters.

If you are really at a loss on how to create these, here is a suggested
format:
	OAFIID:program_name:YYYYMMDD
(where YYYYMMDD is the YearMonthDay thing).

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.

	The Activation ID (AID)

These are strings that tell how to bootstrap a specific object
instance. This means that environmental information such as hostname,
user, etc. They have the following format:

OAFAID:[IID,user,host,domain]

IID format has been described above. 'user' is the login
username. 'host' is a DNS domain name or stringified IP
address. 'domain' is a string describing what use area the object has
- normally this will be 'user' (XXX not clearly defined yet).

Manual creation of AIDs is unsupported - instead, just store and use
the ones returned by the activate() operation.

[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,

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

	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.

	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 ]

	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.

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


	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.
	Then we add either the former or both of these tags:

	version	- this is the build version of the software.

	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. Perhaps that doesn't
make sense in terms of the necessity to kill oafd on installing
new oafinfo files; however, it would be nice to keep track of
the oaf information for running factories separately, so they
can be upgraded whilst running.

	This is also useful for checking conformance in
development software, such that spurious version mismatch bug
reports don't spring up.

	In a distributed environment it would mean you could
get the most recent component, or a component with a version
in a certain range eg. > 0.52.

	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.

	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.

	Regards,

		Michael.

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