Re: Oaf naming, a proposal.

[Michael Meeks <michael helixcode com>]

Hi Maciej,

	Firstly, many thanks for your prompt and considered reply;

On 29 May 2000, Maciej Stachowiak wrote:
> Objections to using the company name:
> 
> * Company names are not really unique. Trademark law only requires
>  uniqueness within a sufficiently narrow domain.

	If you say so; certainly company name alone is insufficiently
unique.

> * 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.

> * 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.

> 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.

> 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.

> 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.

> 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 ? Perhaps what you mean to say is:

	Each oaf file will henceforth have a unique name based on the MAC
address and a load of other strange things.

	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.

	Furthermore, the issue of gconf [ which I understand has paths too
] is an interesting one. Of course, if we came up with a sensible oaf
naming standard with sufficient uniqueness, we could use the same
hierarchy everywhere eg. in gconf paths, to make the system intuitive and
friendly to the hacker.

> * 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.

> * 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.

> 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 ?

> * 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 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 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.

> 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, I see you are
against; Perhaps we need to discuss more ? 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.

	Regards,

		Michael.

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