Oaf naming, compromise.

[Michael Meeks <michael helixcode com>]

Hi Maciej,

	After your lengthy discussion I have come to see that we have to
accept these huge ugly numbers =) but I think several things need doing:

	Firstly restrict the IID charset to 'A-Za-z0-9', '.', '-', ':'.
This will help activation monikers a lot, and can be done simply. I'll
hack this up quickly.

On 30 May 2000, Maciej Stachowiak wrote:
> To me, human-readable and expandable are subordinate goals to
> "globally unique".

	Ok; I can't be bothered to argue this any more, and I agree more
now.

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

	As a peripheral issue, I am not convinced that the OAFINFO_PATH
solution is good enough alone. Where should ISV's set this path ? you keep
saying that millions of components will be written, should we not provide
a nice easy way for them to register themselfs ? perhaps I am being dim,
but I see no method for setting this environment variable that is anywhere
near as trivial as installing your files into a nicely segregated
filespace and them being automaticaly detected. Either way I think the
disagreement is specious, since your argument from what I understand is 2
fold:

	a) more than 1 directory is too slow.
	b) ISVs will install into another directory [ to avoid namespace
conflicts ] and will setup OAFINFO_PATH.

	It seems to me that it might be just easier to poll the
few sub directories that exist in the oaf directory. We might mandate a
company name primary deliniation, which would leave performance
undiminished with a single gnome directory for the current files.

> I'm not sure how gconf ties into this.

	Consider this; a project baa has the following namespaces:

Vendor: foo
Product: baa
Component: kippers

Currently they would store their gconf configuration information in

foo/baa/[kippers]

Their IDL could be

module GNOME {
	module kippers {
	}
}

Their Oafinfo filename could be as bad as

kippers.oafinfo

Their Oaf IID could be

OAFIID:kippers:adf30e75-3b63-4360-8784-a8e239390a6

Hence the namespaces are all confused, and potentialy conflicting. I would
propose then that we mandate / reccommend / whatever that we do:

gconf: /foo/baa/
IDL: module foo { module baa { } }
IID: OAFIID:foo:baa:kippers:adf30e75-3b63-4360-8784-a8e239390a6
OafInfo: oaf/foo/baa-kippers.oafinfo

	I would reccommend that we use oaf/foo/baa/kippers.oafinfo but you
seem to be worried about performance without having profiled =)

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

	Yes, as a matter of fact I do. This only sounds ridiculous since
it would be a pain to setup your PATH, if your shell treated this
namespace as flat it would be sensible. I could then delete all the ppm
related binaries easily eg. The analogy is not a particularly parallel one
however.

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

	Sounds interesting to me. When I discussed FAM/IMON with Miguel,
he said that he and Linus had discussed the best approach and prefered
select on the directory [IIRC]. Not a debate I know much about, enlighten
me.

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

	Well, if a moniker includes an activation IID [ as it may well ],
and the IID contains an arbitary mish-mash of characters, it would seem to
me rather difficult to determine where the IID ends and the string starts,
at least without lots of escape characters that just make life more
painful.

	Regards,

		Michael.

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