Re: VFS for legacy apps

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:


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:


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:


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)

**) - 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,...)


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