Re: Sharing methods among several modules



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.

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.

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

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

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an unconventional soccer-playing ex-con trapped in a world he never made. 
She's a cosmopolitan gypsy pearl diver with the soul of a mighty warrior. They 
fight crime! 




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]