Re: VFS for legacy apps

[nf2 <nf2 scheinwelt at>]

Alexander Larsson wrote:
> On Thu, 2007-02-22 at 12:38 +0000, Damon Chaplin wrote:
>   
> > On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote:
> >
> >     
> > > However, the first method you describe:
> > >
> > > ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt
> > >
> > > sounds perfect. It's rich (we can get back the mount info later),
> > > extensible (we don't have to figure out the entire set of potential
> > > mount options in advance) and fairly simple (the root nodes are all
> > > direct children of ~/.mounts).
> > >       
> > You're probably always going to need type, server and share though, so
> > maybe you can make it a bit more readable:
> >
> >   ~/.mounts/smb:$server:$share/dir/file.txt
> >
> > Extra options can go on the end.
> >
> > Also I'd probably avoid ';' just in case bash goes anywhere near it.
> >     
>
> Sure, those are requred. But say we have two optional things, like user
> and domain, as in smb:server:share:user:domain. But what do we then do
> if user is unset, but domain isn't. I guess one could do
> smb:server:share::domain. Still, it requires very specific handling of
> each type of share with a specified option order etc. A key=value
> approach is more generic.
>
>   

i believe you have to decide between the two models - either always use 
"fuse" - or never use it - and stay with the "stateless" approach (which 
allowes automounting and that protocol handers interact with the user).

1) the "fuse" approach:

i think storing the mount information in the mount path would look 
really horrible (it might show up everywhere). i would rather let the 
user pick a mount-name in the mount dialog - he should really be aware 
of the mounting model - and store the "remount" information 
(user server,port) somewhere else (in mconf files). the "mounts" dir in 
the home-folder should be visible:

~/mounts/myftpserver1
~/mounts/mysmbshare2
~/mounts/.mconf/myftpserver1.mconf
~/mounts/.mconf/mysmbshare2.mconf

i think in the fuse-model there should be no privileged bypassing of 
fuse with gvfs, KIO, dbus etc - fuse just *is* the "vfs". uris are not 
used for file-management.

2) the common vfs library approach:

that's what i'm trying to achieve with "libvio"**): a library below the 
desktop and toolkit layer, below GLib, Qt,... which can be used by 
everyone (can be plugged into any mainloop,...).  we would stay with 
"uri's" (i have a VioFile class to deal with them), have some "stateless 
behavior"*) (automounting, popping up dialogs through an ui-server or 
handlers bringing their own gui.) the vfs-interface would be a lot 
richer than the rather limited posix interface of "fuse" - vfs 
operations emit authentication, progress, queued events, there will be 
rich file-info structures etc...

in the "shared vfs library approach" we would not use "fuse", but rather 
make the shared interface accepted as the only file-management interface 
for desktop apps (also for "legacy apps"). KIO, Gnome-VFS and GVFS 
should also use this interface (just like everyone links to XLib)...

*) i wouldn't call this "stateless" - "stateless" IMHO  is the current 
model of KIO and Gnome-VFS, beeing unable to see an external resource 
(user server) as *one* object (like a mountpoint -  sharing outbound 
connections or synchronizing access - like "writes" to archives etc...  
- that's why archives AFAIK are read-only in KIO/Gnome-VFS)

**) http://www.scheinwelt.at/~norbertf/devel/vio/ - i put a little 
illustration there. libvio already provides all the the major 
vfs-operations (but of course it's still a rough prototype). the reason 
i continued developing this - although i think GVFS is really cool - is 
that it believe GVFS is still located one layer too high to get accepted 
as common infrastructure... (too "Gnomeish", linking to GLib and 
GObject,...)

regards,
norbert