Re: 2.4 Proposed Modules - nautilus-cd-burner and gnome-vfs funkines s



On Fri, 2003-05-09 at 10:27, James Henstridge wrote:
> Murray Cumming Comneon com wrote:
> 
> >So, there's a danger of another load thread here, but I can't help myself.
> >I'm sorry for the rambling nature of this email - it's because I see a
> >problem but not a solution:
> >
> >I'm not happy with the way nautilus-cd-burner exposes the funky burn:///
> >gnome-vfs protocol/location, or with the strangeness of having a virtual
> >stuff-that-I-might-burn-soon location via the file manager.
> >  
> >
> [snip interesting comments]
> 
> I think the major reason for the proliferation of URI schemes is because 
> that is how gnome-vfs is structured.  You write a gnome-vfs module, and 
> it handles a virtual file system under a given URI scheme.
> 
> There isn't really any way for one vfs module to easily delegate control 
> of a subtree to another module without a fair bit of work.  If gnome-vfs 
> had facilities for setting up these sort of "mount points", then people 
> would probably use them.
> 
> I don't think people are going round creating new URI schemes for the 
> hell of it.  I also don't think they are doing it to piss off Daniel.  
> But in the current framework, that is the direction they are pushed.

We talked about x-gnome:/// less than a month ago, as possibly somewhere
under which you could mount different VFS modules. Then you only have
one weird URL scheme. It would have to be implemented in conjunction
with nautilus UI improvements to hide the URL.

My personal view is that we should worry less about the scheme:/// mess
until someone has the time to improve the framework so the idea above,
or something similar, can be implemented. Until then, it's the way
gnome-vfs works.

-- 
Andrew Sobala <aes gnome org>

"A freudian slip is when you say one thing but you mean your mother." -- unknown




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