Re: Oaf naming, compromise.

[Maciej Stachowiak <mjs eazel com>]

Michael Meeks <michael@helixcode.com> writes:

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

Please tell me how restricting the IID charset will help. I don't
really mind doing it (commas are already illegal), but I'd like to
know why.

> On 30 May 2000, Maciej Stachowiak wrote:
> >    
> > 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. 

OAFINFO_PATH is necessary anyway. Third-party applications are
supposed to be installed in a directory of their own under
/opt. Installing some random files in a partitioned filespace under
/usr is not an option. Basically only things that come with your
distribution are supposed to go under /usr/share/oaf.

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

As I said above, OAFINFO_PATH unavoidable. But that doesn't mean we
should have to deal with the same mess for files that come with the
OS distribution.

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

Presumably there would still be (according to your system) multiple
subdirectories under GNOME. The performance issue is a minor side
issue anyway; the real thing that bothers me is the unnecessary added
complexity.

[... discussion about gconf snipped until I have time to think about
it ...]
 
> > 
> > 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.

Well if /usr/bin were organized by vendor, most things would be under
gnu/something, which would be unhelpful.

By vendor is just not (IMO) a useful method of organization from the
user's point of view. The user shouldn't need to care where a
program or component comes from, only what it does.

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

select() on a directory lets you lose events. You won't get info about
any events that happen on the directory while you are not select()ing
(unless you massively change the semantics of select()), and you will
need to wake up out of the select() at least briefly each time you get
an event. "Tell me when this directory changes" is a pretty different
kind of question from "Tell me when this file descriptor is ready for
input" because you really don't care when it _becomes_ ready for
input.

 Someone is supposedly implementing inode monitoring with
real-time signals, but that seems like a rather painful approach for
user code.

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

I'd rather not change it until I know where exactly the IID would
appear in the moniker so we know what characters it makes sense to
ban. Note that commas are already forbidden so they can be a delimiter
of last resort.

 - Maciej