system and desktop VFS merged

[Lars Hallberg]

Sean Middleditch wrote:

>I really see no purpose in using the VFS path stuff.  Classic UNIX uses
>mounting.
>
I can se a smal point. If You configure an viewer for a filebrowser 
using some syntax, say "foo %u" for an app that want an uri, and "foo 
%f" for an app that want an pathname. Then the filebrowser can easy 
translate the uri to an path if it is avalible. That is some usefullnes 
in that!

But i think the /vfs structure have problems. What if more than one user 
mount ther home directory over the same protocoll from the same server? 
Then we need username in the pathname.

If the D-VFS deamon keep track of mountpoints, it can provide that 
translation anyvay. And any filebrowser that need do the translation 
just must be D_VFS avere!

>  If a user wants their legacy app to access a remote share,
>they should mount it just like they currently do with sshfs or smbfs or
>whatever.  They can mount it anywhere they want - I usually mount remote
>shares in ~/.mount/ for example.  If a user wants a dynamic mount area,
>I'd suggest having the individual users mount such a dynamic filesystem
>in their home folder as well.
>  
>
You talk about somthing like dvfsmount that take an uri insted of an 
device? I would be verry happy with that. Like that kind of controll 
over what get mounted where :-)

If the D-VFS demon keep track of the maintpoint and can do uri -> path 
translation it good enuf for all I can think of :-)

a smal tool for translation maybee so You can type:

$ emacs `dvfspath ssh://foo.org/bar.cc`

or

$ cd `dvfspath ssh://foo.org/`
$ make

And it works if ssh://foo.org/ is mounted somewher, wherever the user 
prefer.

Then some optional automounting featur can be added for user that want 
that. I don't think I'm one of them. If the D-VFS deamon and api can 
tell what conections are 'up', or even - a proc can ask to licening on 
all vfs conect/disconect events thru D-BUS... Then writing such 
'standalone' automounter must be simple.

/LaH