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 ([EMAIL PROTECTED],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 ([EMAIL PROTECTED]) 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 _______________________________________________ gnome-vfs-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
