An entirely different angle on the GNOME VFS

[Dominic Howells <mail-list domhowells com>]

Having read the recent posts on volume handling I cant help feeling that
we are really barking up the wrong tree with how we handle modern issues
like digital cams, mp3 players, zeroconf networking. My proposition is
much more intune with the UNIX os and filesystem itself; although you
might view it as backward looking or linux centric. So suck it and
see....

The Problem
===========

	VFS is essentially a toolkit-level hack to get around flaky support for
storage, 0conf, pseudo-filesystems (cameras), etc, in the OS itself. To
its credit because of this it manages to be relatively portable. However
my feeling is that it is inappropriate for the toolkit/desktop to be
'propping up' outdated or incomplete support in the OS. Lets look at
linux however: I know we run on other OSes, but linux is the main gnome
desktop userbase, and frankly if Linux can support PROPER vfs
implementation by way of a userspace deamon, then so can commercial
UNIX, BSD, etc. And linux DOES have the kernel framework to acheive this
'proper support'.

So what is a 'proper' VFS?
==========================

	Unix was not blessed with mountable volumes, multi fs support, network
mount support, et alia for nothing. Such features are available in the
kernel and for this reason alone we should use them. Aferall nothing
will help inter-application and inter-toolkit support more than a decent
implementation at OS level of filesystem issues. Try writing to burn:///
under OpenOffice. See What I mean? What we should do is implement OS
calls to mount filesystems of any description in a logical, coherent,
and easy way rather than fannying around with our 'private' gtk
filesystem.

What I propose
==============

	A deamon, lets call it vfsd which loads at boot time with root
privelages and manages /vfs in the same way as devfsd manages /dev. The
linux kernel now has support for deamons managing parts of the
filesystem, and support would not be difficult on other OSes. We fire up
this program at boot, making sure it is aware of the config files like
/etc/fstab and system-wide vfsd configurations. The deamon remains aware
of who owns the console (i.e. the current logged in user) given we can
suppose that whoever is logged in at the console and is sticking cameras
in the USB hole has the rights to use them. /vfs should be populated
(like /proc) with an outline of the various devices in the form of
directories labeled such as network, peripherals, storage, cdburn, root
(symlink), home (symlink) etc. I will now outline how we acheive the
various tasks commonly undertaken with the existing vfs system.

	Standard Removeable Media: Floppy, DVD, CDROM, usb-mass-storage

	When the user tries to enter the directory /vfs/storage/floppy the disk
is mounted if there is one there, during this the vfs stalls responding
the the request to browse the directory. If mounting succeeds the user
can browse/write/etc, if mounting fails we return a standard unix FS
error to the client (See the beautiful standards compliance yet? And the
best bit is that as we're using standard system calls we can exhibit the
same behaviour regardless of weather a gnome app, a kde app, or even
someone in an xterm tries to access the floppy). And once the last
program has left the directory we unmount. With CD/DVD devices we just
mount as they are inserted, and trap the eject key if possible to
unmount then soft eject. If we cant trap eject then we just use the same
system as floppies of last-program-out unmounting. Of course all these
mounted things are owened by the console user with standard 644
permissions or whatever. As for usb we mount (synchronously i would
prefer) on insertion and then unmount after hard-removal with no data
loss. We can also treat UFS CD-RWs similarly to USB-mass-storage. Same
goes for usb-mass-storage cameras, external hdds, mp3 players etc.

	Removable hardware that is not exactly a storage medium but makes sense
as one (ie. wired dual purpose webcams, mp3 players that can be made to
play via remote command):

	Such things as these which cant be dealt with as filesystems on a
kernel level (i.e. a driver normally deals with them and provides
extended functionaliy, for example funny camera drivers that give scope
for storage and webcam mode etc). So what do we do? vfsd calls the
appropriate userland driver to deal with these things and then uses its
position of managing its vfs bridge the driver to a mounted fs directory
/vfs/peripherals/camera. The non-fs funcionality like webcam mode is
dealt with by a progrem (eg vanity) talking to the driver itself.

	CD-R or similar:

	The current user owns /vfs/cdburn and can write to it and then execute
the required combination of mkisofs, cdrecord, rm -rf /vfs/cdburn, etc,
or of course have a button on their Actions menu do it for them.

	Network:

	Once a user enters /vfs/network we basically handle zeroconf and all
the rest of it like people are proposing for network:/// at the moment.
Myself I am not a fan of mounting ftp connections etc, however for SMB
and NFS I'm sure this is quite appropriate. You should be able to fill
this in in your mind, following the principles outlined above.

	Local stuff being in /vfs like the root directory, /home/$USER, etc are
dealt with by symlinks.

To please you usability fans
============================

	Clearly the user would not have to be exposed to such horrors as
directories reading /vfs/peripherals/camera needing to be typed into the
address-line. However once you have a coherent backend like this you can
put as much user-friendly cruft infront of it as you like such as: Icons
on the desktop displaying all active mounts in /vfs (from mtab for
example), or linking to /vfs/network via a desktop icon entitled 'browse
the network'. gnome or any other desktops can paint it however they want
but there is something underlying which means one can still go to an
xterm and do:

cd /vfs/network/
ls
cd server1/smb/share1/
cp file1 ~/docs/

which is something we certainly CANT do with the current vfs unless we
rewrite all the gnu tools to understand fonts:/// et alia. Given that i
consider network:///, burn:/// all-porn-under-mnt-windows:/// or
whatever other incredible URIs you dream up, an utter abhorrence I for
one would be pleased to see us go back to dealing with real FS
directories.

I'd love to hear your thoughts on this guys.

Dom.

-- 
Dom Howells | e: dom domhowells com
t: 01844 339355 | m: 07956 224714