Oaf naming, a proposal.

[Michael Meeks <michael helixcode com>]

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.

	Thanks,

		Michael.

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