Re: monikers, gnome-vfs (again :-)

[Maciej Stachowiak <mjs eazel com>]

Michael Meeks <michael helixcode com> writes:

> On 18 Dec 2000, Maciej Stachowiak wrote:
> > Miguel de Icaza <miguel helixcode com> writes:
> > > Something like that already exists.  But there is a problem on keeping
> > > in sync the VFS prefixes registered in the moniker space.  For each
> > > new prefix supported by the VFS you need to install an .oafinfo file.
> > > 
> > > Or we need to extend bonobo.
> > 
> > I'd love to add support to Bonobo to be able to have a single Moniker
> > implementation handle more than one scheme.
> 
> 	This is already 100% possible, simply sub-class BonoboMoniker and
> implement the methods; bingo. This is not the problem per se; there are 2
> problems, 1 is that the oafinfo activation assumes a string not a stringv
> for 'bonobo:moniker' which denotes the prefix, and the 2nd problem is that
> you don't know the prefixes until runtime. Problem 1 is a 1 line query
> string change, + fiddle some oafinfo.

What I was proposing is to send a patch for problem 1 for the sake of
future extensibility. Due to problem 1, having a single Moniker
implementation handle multiple schemes is currently 0% possible. Do
you want a patch that will upgrade that to the theoretical 100%?

Problem 2 is unrelated to this, except that it would also have to be
solved to have a nice general-purpose gnome-vfs-based moniker. It's
good to solve problem 1 (since it's so simple to do) even if problem 2
is not solved right away.

> 	The not knowing the prefixes problem is intractible with the
> current setup, without adding a special hook for this case which sounds
> ugly; it's possible there is a clean solution though.

It's sort of a problem in general with things described by oaf and
things whose capabilities vary at runtime depending on other installed
software. I'm hoping there will be relatively few occasions where that
happens so we can suffer the few special cases, unless someone has a
good design for addressing this problem.

> > Also, the fact that gnome-vfs supports a runtime-dynamic set of
> > schemes is tricky to handle in other parts of the system too. I
> > suggest we use "(vfs)" or something as an alias for "all URI schemes
> > that gnome-vfs knows how to handle", although in the case of monikers
> > this leaves a parse-time issue of knowing when to let a vfs moniker
> > (if present) do the parsing.
> 
> 	This paragraph totaly bemused me;

What a great way to say "I don't understand what you mean." I'll have
to remember that one.

> where is this alias '(vfs)' defined ? who sees it ? what does it do?

My proposal is: you just say "(vfs)" in lieu of a specific URI scheme
when you support all URI schemes that are supported by gnome-vfs,
wherever URI schemes would be listed to specify capabilities.

It's not "defined" except by the definition above. Everyone sees it
who would otherwise see a list of URI schemes. It doesn't do
anything. It's just a string.

If you have a better concrete proposal, I'd love to hear it - this
problem needs to be solved for .oaf files and the mime/application
database files as well. 

My proposal is pretty week on a number of fronts, but I haven't yet
thought of anything better (other alternatives that came to mind would
involve requiring everything in the world to link to gnome-vfs, or
inventing a whole new separate library that does nothing but parse the
gnome-vfs module config files).

Regards,

Maciej