Re: Sharing methods among several modules

[Magnus Bergman <magnus bergman observer net>]

On Mon, 29 Aug 2005 16:59:06 +0200
Alexander Larsson <alexl redhat com> wrote:

> On Mon, 2005-08-29 at 15:32 +0200, Magnus Bergman wrote:
> > On Mon, 29 Aug 2005 09:46:27 +0200
> > Alexander Larsson <alexl redhat com> wrote:
> > 
> > > On Fri, 2005-08-26 at 16:46 +0200, Magnus Bergman wrote:
> > > > There has for a long time been a confusion between the protocol
> > > > prefix of an URI and volume labels (as in AmigaOS and NetWare).
> > > > For example GnomeVFS uses the URI computer:/// to access the
> > > > virtual "computer directory". The idea (I assume) is that it
> > > > should appear as a volume label called "computer:", but the URI
> > > > of such a label should really be file://computer|/ (or is it
> > > > file:///computer: ?).
> > > > 
> > > > The problem here is a limitation in GnomeVFS which only allows
> > > > one module to handle each method. Thus each new module needs to
> > > > allocate a new method (fake protocol). I decided to fix this by
> > > > making a module which can "mount" other modules in the same
> > > > tree, or make them appear as volume labels. The idea is to have
> > > > this module handle the file-method and mount the file-module as
> > > > root, and then have the possibility to mount other modules
> > > > (such as the computer-module) at other places in that tree. Is
> > > > this a reasonable approach, would it even be suitable for
> > > > inclusion in GnomeVFS?
> > > 
> > > I don't understand at all why you would ever want something like
> > > this.
> > 
> > The main reason is that I think it's wrong to invent a "fake
> > protocol" for each new module (I'm not just talking about the
> > included modules but every potential module also). It was a lot
> > worse in older versions of GnomeVFS, but there still is a confusion
> > between protocol prefixes (like HTTP://) and volume labels (like
> > themes: or something). I want to fight this confusion. Every module
> > that doesn't really implement a protocol should be accessed through
> > the FILE:// method, I think. And either "mounted" in a virtual file
> > system or assigned a volume label (my module supports both) that
> > works the same way as on systems which has volume labels. I assume
> > it would be done like this already if GnomeVFS had support for it.
> 
> I don't understand why adding the intial string to a uri is "wrong",
> but adding it to the second part, after a "file://" string its
> suddenly ok. All that does is create a fake file that doesn't really
> exist, and be totally incompatible with all other users of file: uris.

Because the first part of the URI string is the protocol (or access
scheme). The file:// prefix doesn't necessarily mean that it's a
physical file, just that it's a part of the local file system. See RFC
1630. Yes, I think it's much better to pollute a virtual file
system with virtual directories (and/or volume labels) than to pollute
the protocol name space with fake protocols. Then having more then a few
modules (which creates virtual files from databases in various ways) I
found a need to group them together in the same tree.

You are probably right about that it has disadvantages if the
GnomeVFS API shows more and/or different files that the posix API (but
it works fine for me). This was slightly beside the point. The point was
just to offer the possibility to access (virtual) files provided by
several modules through the same method, not even force that option
onto anybody. To keep this totally abstract, it makes it possible to
access the virtual file trees provided by the modules bar and baz
through the method foo, like this:

foo:///bar/
foo:///baz/

Or like this:

foo:///some/directory/bar/
foo:///some/directory/bar/some/other/directory/baz/

I should probably have limited my first mail to just this (abstract and
non-scary) example. This is how my module works. How it should, and
shouldn't be used is another question, in which I don't have a strong
opinion.


> Also, i don't know why you call some vfs methods "volume labels" and
> some protocols. They are all just vfs methods. I've never seen any
> confusion about this before.

To me it's quite clear that some methods provide protocol access (like
http and ftp), while others don't (like computer and theme). It doesn't
have to be a volume label if it's not a protocol, but I guess it's the
intention to make it look like one. Am I wrong?

GnomeVFS used to have a feature to access virtual directories through
"fake protocols" like applications:// and control-center:// (perhaps I
remember their names incorrectly). I guess this was inspired by system
which has volume labels, like AmigaOS. On those systems the volumes are
considered to be a part of the local file system (since the are handled
by the OS), thus their URI becomes file:///volume-label|/ (Or just
volume-label: if it's not encoded as a URI). I don't think the URIs
should look different just because the implementation is different (in
user space instead of in kernel space).

Then I wonder how GnomeVFS handles this on the systems which has volume
labels. On DOS based systems for example. Are the floppy accessed
through a:/// or file:///a|/? And if I map a NetWare volume (called,
let's say data:) on such a system should it become data:///,
file:///data|/ (the probable case) or perhaps netware:///data|/?

This is the confusion I'm talking about.


> > In a default installation we now get:
> > 
> > computer:///
> > fonts:///
> > themes:///
> > 
> > This is bad if you ask me, especially if even more modules are
> > added. (I have made a couple of custom ones and I guess I'm not the
> > only one). I don't have a strong opinion about exactly how this
> > should be done the right way. But for example it could be arranged
> > like this:
> > 
> > file:///computer/
> > file:///computer/fonts/
> > file:///computer/themes/
> > 
> > Or perhaps like this:
> > 
> > file://computer:/
> > file://computer:/fonts/
> > file://computer:/themes/
> 
> I'm not sure why adding the string "file://" to any vfs uri would make
> much difference with anything, except being confusing (since the
> normal definition of file: doesn't do that, and there is not such
> file).
> 
> Not to mention that this change is totally backwards incompatible.

I don't agree that it would break the definition of the file:// method
(there are already completely virtual file I can access like
file:///proc/version). But I absolutely agree that my example is very
bad as a default configuration of GnomeVFS. It was merely an example of
what can be done, not that I want to force upon everybody (I can do
this on my own computers anyway).


> In short, i don't think we're very interested in this.

Understood.