Oaf naming, a proposal.
- From: Michael Meeks <michael helixcode com>
- To: Elliot Lee <sopwith redhat com>,Maciej Stachowiak <mjs eazel com>,Miguel de Icaza <miguel nuclecu unam mx>
- Cc: gnome-components-list gnome org
- Subject: Oaf naming, a proposal.
- Date: Mon, 29 May 2000 11:13:01 -0400 (EDT)
File Namespace, each oafinfo file must be stored in a path, this
equivilant to a namespace, since no two files must have the same
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
Random number Namespace, can provide highly probably globaly
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]
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:
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.
email@example.com <><, Pseudo Engineer, itinerant idiot
] [Thread Prev