Re: Wake up on IIDs



Michael Meeks <michael@helixcode.com> writes:

> Hi,
> 
> On Tue, 23 May 2000, Elliot Lee wrote:
> > > There's a problem with such identifier scheme: it needs a central
> > > authority which prevents for a company named "FooSystems" in EUA and
> > > "FooSystems" in France England with the same "SuperMailer" program to
> > > choose the same OAFIID.
> > There will be bigger problems than OAFIID conflicts if such a contrived
> > case ever actually happens.

Just because one namespace is poorly managed, that's no reason to let
other things break. Unix program names _do_ conflict. Perhaps you
recall the Easy Editor vs. Electric Eyes fight over the name `ee'. And
those were both widely distributed free software programs. As a last
resort, binaries with the same name can be installed in different
$(prefix)es. However, if one installs different oafinfo files that
contain the same IID referencing different objects, no amount of
installing in different prefixes will make the system coherent.

> 	Amen. So, I have been extremely underwhelemed by the level of
> engagement by the magic number brigade. It appears no one is in favour of
> it, and either way it is horribly flawed. I propose to write a document on
> how to do it right, and commit to CVS.

On the contrary, no one seems seriously opposed to it but you, and as
far as I'm concerned you have yet to articulate a meaningful argument
against it.

I am willing to read an alternative proposal with an open mind however.

> 	Furthermore, I forsee a nightmare coming, and this is perhaps we
> have lost the plot. We already have a namespace that is getting crowded:
> 
> 
> nautilus-content-loser.oafinfo
> nautilus-hardware-view.oafinfo
> nautilus-music-view.oafinfo
> nautilus-sample-content-view.oafinfo
> nautilus-sidebar-loser.oafinfo
> 
> ntl-web-browser.oafinfo

We've stopped using the "ntl-" prefix, we've renamed all our files to
start with nautilus- (although you might have garbade ones left
around). BTW, I hardly see a bunch of files all starting with an
appropriate namespace prefix as a sign of a namespace getting badly
crowded.

> And:
> 
> evolution-calendar.oafinfo
> addressbook.oafinfo
> evolution-mail.oafinfo

addressbook.oafinfo is probably not a great name.

> etc.
> 
> 	IMHO we have here a namespace that is getting increasingly
> unstructured and crowded already. So this sucks really badly, this is
> quite apart from the issue of uniqueness of unix filename [ although this
> can be obviated by an explicit path ].

I don't see the problem. For the free software world, we can assume
reasonable amounts of cooperation. For proprietary software, we can
assume installation in /opt or something. This is really no worse a
problem than the potential of conflicting executable names.

> 	So, I will now take a chunk of time and propose a more sensible
> method for creating names, as part of this I will suggest an improved
> organisation of the $(datadir)/oaf directory based round the encoding.
> Then I hope we can move to fixing this problem fast and retrofitting the
> 40+ oafinfo files we already have.

Feel free to write it, but I don't see either the current IID scheme
or the (lack of) organization of $(datadir)/oaf as grave problems. So
your proposal had better be really convincing. :-)

 - Maciej





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