Re: Oaf naming, a proposal.

[Maciej Stachowiak <mjs eazel com>]

Michael Meeks <michael@helixcode.com> writes:

> Hi Maciej,
> 
> 	Firstly, many thanks for your prompt and considered reply;
> 
> On 29 May 2000, Maciej Stachowiak wrote:
> > * There is no appropriate handling for independent free software
> >   projects. Using a catchall namespace like "GNU" or "GNOME" just
> >   means that portion of the namespace conveys 0 bits of information
> >   and may as well be omitted.
> 
> 	True; but then again, in the free software community we mostly
> have an enlightened view of cooperation and naming, not available to the
> ISV community.

I don't think that's the case. Note the `ee' conflict. I bet more such
conflicts could be found if you look hard enough.

> > * It gives too much attention to the company. I wouldn't want Nautilus
> >   in the Eazel: namespace, I'd want it in the GNOME: namespace. I
> >   imagine non-eazel contributors think they have been contributing to
> >   the GNOME project, not to Eazel.
> 
> 	A valid point, and perhaps GNOME is a good namespace for nautilus,
> I cannot concieve of another program called nautilus in the GNOME
> namespace however. Again the naming convention is mostly to help the ISV.

But it needs to help volunteer free software hackers too.

> > Objections to using the project name:
> > 
> > * Software product names definitely do not have to be unique; only 
> >   within the same category of software. Even in the free software   
> >   world where we are supposed to be all cooperative and stuff (and
> >   there are fewer total projects than in the commercial world by a
> >   long shot), we've had naming collisions.
> 
> 	Sure, but in the commercial world there are non-conflicting
> company names, furthremore I would argue that many of these name conflicts
> are based on the shell hackers love of terse command names such as 'mc',
> 'ls', 'ee' etc. This problem tends not to apply to desktop software to the
> same extent.

I bet if I looked hard enough I could find pieces of proprietary
Windows software with the same name, or shareware for that matter,
which do different (or perhaps even similar) things. But I don't care
enough to prove the point. Suffice it to say that with enough people
doing the naming, names will be reapeated.

> > Objections to the claim that "company" + project name are
> > sufficiently unique:
> > 
> > * Just count the number of GNOME/Gtk+ IRC clients. Imagine now that
> >   there are 20 times as many free software hackers in the world as
> >   there are today (all using the GNU or GNOME namespace) and that each
> >   feels compelled to provide a Bonobo component.
> 
> 	It would seem that each Gnome IRC client has a different name,
> they are not all called 'xchat', people avoid project name clashes quite
> carefuly.

I really wouldn't be surprised if more than one person chose to call
their program gnome-irc or girc (not saying this has happend - just
saying I wouldn't be shocked if it did; there is no central registry
of project names really).

> > Objections to the user's discretion portion
> > 
> > * If it's not standardized, why bother.
> 
> 	Well; the 'users discretion' portion could contain an unfeasibly
> ugly non-human readable number for the ultra paranoid, it would also allow
> truly sprawling companies to further segregate their namespace. I am not
> interested in enforcing this on anyone, merely reccommending a sensible
> conflict free human-readable, expandable standard.

To me, human-readable and expandable are subordinate goals to
"globally unique".

> > Objections to the directory hierarchy:
> >   
> > * It adds no real benefit other than pleasing Michael's aesthetic
> >   sense.
> 
> 	Hah =) I find this incredible. On one hand you are advocating
> horrendously unique massive numbers, whilst you are saying on the other
> that installing a load of files into an uregulated conflict prone file
> space is a sensible thing ?

For reasons I stated in my message (but which you apparently snipped
all instances of), IID conflicts are actually more severe than
filename conflicts. You can install files with the same name in
different prefixes if ncessary, but this will not help for conflicting
IIDs. Further, filename conflicts will be discovered immediately at
install time and can be dealt with by installing into a different
prefix or renaming; while IID conflicts will not be discovered until
things mysteriously break in some fashion, and cannot be resolved short
of modifying the program source code in many cases.


> 	I think to avoid the namespacing question is to seriously
> underestimate the problem, that directory is whether one likes it or not a
> namespace and it would be good to regulate it.

You can solve namespace conflicts in it by installing some of the
files elsewhere. I don't see it as any more problematic than /usr/bin
really. In fact, less so, because installing in a different prefix
won't even result in worries over what is first in your path. Two
files with the same name can both be in your OAFINFO_PATH just fine.
 
> 	Furthermore, the issue of gconf [ which I understand has paths too
> ] is an interesting one.

I'm not sure how gconf ties into this.

> > * It makes the code for reading oafinfo files more complicated; now
> >   for each directory it scans, it must do a deep search instead of a
> >   flat file scan.
> 
> 	This is true, but perhaps an acceptable tradeoff for namespace
> cleanliness.

Hmm. Do you think if we organized /usr/bin the same way it would be
helpful to the user? I don't. So I'm still not convinced.
 
> > * More importantly, it makes the code for detecting when an oafinfo
> >   file may have changed more complicated; instead of one directory
> >   stat() per item in the search path, it would have to do many. This
> >   is a serious problem that will slow things down.
> 
> 	Currently the stat happens every ~5 secs, I know not how much
> slower it will make it, however I do know that in future it is likely that
> a select on a bunch of open directory file descriptors will do the same
> thing for us in a single operation with no real performance hit. So I
> don't believe it will be significantly slower in the short or long term.

(total irrelevant side point: select() is not the right interface for
directory monitoring for many uninteresting technical reasons)
 
> > General objection:
> > 
> > * I'm not convinced the current system is broken. Thus, I am not
> >   especially inclined to fix it (and particularly to go around
> >   modifying all the oafinfo files out there and making them install in
> >   strange directories.
> 
> 	Well; I am quite happy to do the work, perhaps I didn't make that
> clear. Secondly, is it not obvious that the directory $(datadir)/oaf is a
> [file] namespace ? is this not clearly broken already ?

Not to me, for reasons stated previously.

> > * Comparing Microsoft's UUID-based system for guaranteeing uniqueness
> >   vs. Sun's domain-name based system for Java (which is similar in
> >   spirit to what Michael proposes), I have to say that the uuid system
> >   scales better.
> 
> 	Could you share how you reached that conclusion ?

In very large corporate or educational institutions that don't use
subdomains, people have run into conflicts because the corporation or
university did not set up the local naming authority that would be
required to make Sun's system work well. UUIDs don't need any kind of
naming authority, not even local ones.

Also, projects not rightly associated with any particular DNS domain
name have basically ignored the namespace rules since there is no
sensible way to apply them.

And finally, many projects do not spend their whole life under the
auspices of a single dns-named entity. Consider a university research
project that turns into a corporate spinoff.

Basically people whine about these potentials for conflict all the
time (whether real or not), while no complains that UUIDs may lead to
conflicts. And really there are more COM objects out there than Java
classes, so this fact speaks volumes to me.


> In reality since I started this discussion I have come to like the
> magic number a little more, but I still think we need more structure
> to the file and IID ( and possible gconf ) namespaces, again there
> is no problem putting a 256 hex digit number in the user definable
> section.

uuids are 32-digit not 256-digit. They only really provide protection
for the whole system if they are mandatory, not optional, however.

 
> > * UUIDs are more than just random; they actually are guaranteed
> >   globally unique because they encode the hardware MAC address, the
> >   date, and a sequence number, in addition to random data.
> 
> 	Yes, and I see many advantages of UUIDs, but they are not
> sufficiently structured or readable for my liking.

They are not meant to be readable or structured, they are meant to be
globally unique.
 
> > Hope these comments are helpful. Note: if anyone else agrees that
> > Michael's proposed system is way more awesome than the current system,
> > I'll take that into account.
> 
> 	Well, I think Mathieu is in favour of more human readableness
> since he is a Moniker man, Elliot is in favour of a human readable
> reccomendation such as this, as long as it is not enforced,

Please let's let others speak for themselves.

> I see you are against; Perhaps we need to discuss more ?

You're welcome to keep trying to convince me. I'm not sure our
premises are the same though. I don't see why the IIDs need to be
totally human-readable. I left the human-readable unstructured portion
of the IID in the reccomendation mainly as an aid to debugging
(because it's easier to identify a string + a random number than just
a random number on sight), and not as a suggestion that the human
brain is intended to parse IIDs.

So you will probably have to convince me that human-readability is
extremely important (more so than guaranteed global uniqueness) to
convince me that anything like your plan is worthwhile.

> Miguel what are your thoughts ?
> 
> 	Furthermore, in the spirit of making the monikers easier to use, I
> would propose that we limit the IID character set to AlphaNumeric, ':',
> '-' and enforce that at parse time; but this is a separate issue.

I don't see how this relates to monikers, but I'm willing to limit the
character set if there is some tangible benefit.

 - Maciej