Re: Unique OAF Implementation ID's

[Maciej Stachowiak <mjs eazel com>]

Hi everyone,

Just so everyone here is on the same page, I'd like to point out that
the `IID' in OAFIID stands for Implementation ID, not Interface ID (I
don't think this poster is confused, but another was). Because of the
unfortunate collision with COM (where IID does mean Interface ID), I'd
be glad to take suggestions for other names. Ones I thought of include
OAFOID (Object ID) or OAFCID (Class ID). But those both seem a bit
awkward.

ERDI Gergo <cactus@cactus.rulez.org> writes:

> Hi,
> 
> I've talked with Michael about OAF UIID's, and I realized that
> 	a, what OAF UIID's are about is not clear, and
> 	b, the current cryptic hex numbers scheme is not nice.
> Point a, is that it's not clear wether the IID needs to be unique for
> applications, or for specific versions (i.e. is it `implementation' as in
> `this is the Helix implementation of Wombat' or is it `implementation' as
> in `this is the 0.6 implementation of Helix Wombat'?). It seems to me the
> former is correct, since I have yet to see a package changing its UIID
> with a new release. If I'm not right on this one, please discard point b,.

I think continuing to use the same OAFIID as long as the object
remains backward-compatible with older versions is OK. There is no
reason apps that might for some reason hardcode the OAFIID should
break each time you upgrade an application. If you want to be able to
keep multiple versions of the component around though, each does need
it's own OAFIID.

> Point b, is that if the purpose of the UIID is to identify a
> specific program that implements the given interfaces, why not use
> something human-readable, e.g. the vendor's and the product's name?
> So, my proposal is, something like
> OAFIID:evolution:addressbook-server:helixcode
> instead of the current
> OAFIID:evolution:addressbook-server:0fbc844d-c721-4615-98d0-d67eacf42d80

1) Not every component _has_ a vendor. What if I write my own
   open source component just for fun?

2) Company names collide.

Once there are enough people out there writing components, we will
need a serious way to prevent OAFIID's from colliding. People write a
_lot_ of COM objects today (just go to a technical bookstore and look
at how many COM books you see) and I think many people here would like
Bonobo to be as big as COM someday. So we must be prepared for the day
when huge numbers of people are writing Bonobo objects.

The only two real alternatives are a central registration authority,
or a distributed scheme to generate identifiers that are still
globally unique. I think the latter is much more in the spirit of free
software, and much less likely to be ignored just out of
laziness. This is why I picked the scheme of appending a uuid to
guarantee uniqueness of OAFIIDs.

 - Maciej