Re: Oaf naming, a proposal.

[Maciej Stachowiak <mjs eazel com>]

Michael Meeks <michael@helixcode.com> writes:

> Bonobo/ namespaces.
> 
> File Namespace, each oafinfo file must be stored in a path, this
> equivilant to a namespace, since no two files must have the same
> name.
> 
> Company Namespace, a readily identifiable, suitable globaly unique
> space, would extend to organisation names such as gnu, gnome etc.
> 
> Project/Product Namespace, again suitably unique, no two commercial
> software products should share the same name for legal and
> trademarking reasons.
> 
> Random number Namespace, can provide highly probably globaly
> unique names.
> 
> 	So, the merits of the top 5 are that they are human
> readable and unique, the merits of the random number is that
> it is supposed to be more unique [ ok, so I know something
> uniqueness is boolean, but it's an idiom ].
> 
> 	I have argued for some time that both company name
> and software product name are unique enough alone, and in
> combination extremely unique.
> 
> 	What I propose is this, we will reccommend a naming
> scheme like this:
> 
> OAFIID:[company/org name]:[product/project name]:\
>        [component name]:[factory/object]:[user's discretion]
> 
> eg.
> 
> OAFIID:HelixCode:Evolution:address-book:object:1.0
> OAFIID:Eazel:Nautilus:music-view:factory:foo
> OAFIID:GNOME:Gnumeric:Workbook:factory:bar
> 
> 	Furthermore, I propose that we get shot of the flat
> $(datadir)/oaf setup, and search a directory tree for oafinfo
> files. The Layout would have _NO_ significance whatsoever, beyond
> removing conflicts, hence we would have:
> 
> oaf/HelixCode/Evolution/address-book.oafinfo
> oaf/Eazel/Nautilus/music-view.oafinfo
> oaf/Microsoft/Office/word.oafinfo
> 
> etc. However, of course any of the oafinfo files could be placed
> anywhere in the tree, the layout would be merely to stop
> conflicts, make it aestheticaly pleasing and more manageable.
> 
> 	Can we have some serious comments on this scheme, we
> really, really need to fix these problems before we create a
> massive back-fitting job to fix.
> 

I don't like it. Here are some reasons I don't like it:

Objections to using the company name:

* Company names are not really unique. Trademark law only requires
  uniqueness within a sufficiently narrow domain.

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

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

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.

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.

Objections to the user's discretion portion

* If it's not standardized, why bother.

Objections to the directory hierarchy:

* It adds no real benefit other than pleasing Michael's aesthetic
  sense.

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

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

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.

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

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

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.

 - Maciej