New VFS being developped for glib/Gnome

[Michael Banck]

Hi,

just wanted to point out this presentation done by Alexander Larsson
(RedHat) this week at GUADEC on GVFS:

http://www.gnome.org/~alexl/presentations/guadec2007-gvfs.odp
(temporary PDF version: http://oussik.com/guadec2007-gvfs.pdf )

The code is at http://www.gnome.org/~alexl/git/gvfs.git/ 
(I didn't manage to check it out yet, damn git)

It is further down the stack than the old gnome-vfs (glib) and uses dbus
and FUSE to extend the VFS.

This might be something which could be much more naturally consumed by
the Hurd than previous desktop VFS implementations, so maybe somebody
wants to take a look at it.  At this point, we can probably not propose
large changes to the design anymore, though, but we could replace parts
of it by Hurdish bits.

<marcus> this seems like a design where the Hurd could support the VFS,
        rather than the VFS just ignoring everything under it
<marcus> nice

The original announcement `Plans for gnome-vfs replacement' is here:
http://mail.gnome.org/archives/gnome-vfs-list/2006-September/msg00023.html

A detailed status report has been posted here:
http://mail.gnome.org/archives/gnome-vfs-list/2007-February/msg00005.html

I'll repost parts of it inline for easier consumption:

--8<--

The gvfs code consists of three parts, a library "gio" which has the
API that applications use, a set of daemons handling access to various
file resources (only smb implemented atm), and a dynamic module that
(optionally) gets loaded into gio that communicates with said daemons.

GIO
===

The gio library is meant to be a part of glib. Its a generic I/O
library similar to e.g. java.io.*. Its a "modern" gobject-based
library using things like inheritance and interfaces. As such it can't
be in the main glib library (since that doesn't link to gobject).

Right now it contains these public classes:

GCancellable
GFile
GInputStream
  GInputStreamSocket
  GFileInputStream
GOutputStream
  GFileOutputStream
  GOutputStreamSocket
GSeekable
GFileInfo
GFileEnumerator
GMountOperation
GVfs

Some short explanations:

GCancallable: all i/o operations optionally take one of these so
that you can cancel the operation from another thread (for sync i/o)
or from the mainloop (for async i/o).

GFile: an abstract reference to a file. These are cheap to construct
and handle (i.e. creating one doesn't do any i/o). Consider them an
abstraction of a pathname. In fact, for local files they are just a
filename. Generally we want to avoid handling strings like uris/and
filenames in application code. It only leads to problems with things
like filename escaping etc. The general approach is to construct a
GFile from a filename or uri once, and then use things like
get_parent() and get_child() to navigate the filesystem.

GInputStream, GOutputStream: These are abstract stream base classes
that support both sync and async i/o. For subclasses that only
implement sync i/o there is a thread-based emulation of async
i/o. Compare to java.io.InputStream or System.IO.Stream.

GSeekable: Interface that streams of any type can implement if they
support seeking.

GInputStreamSocket, GOutputStreamStocket: stream implementation for
regular sockets. Created them from a file descriptor. This is
implemented because its used heavily in the daemon communication code.

GFileInputStream, GFileOutputStream: Abstract subclass of the regular
streams that add some features that streams from files typically have,
like seek, tell, and fstat. All the operations on GFile that return a
stream return a GFileStream.

GFileInfo: An abstraction of struct stat. It has a few "hardcoded"
attributes like type, name, size and display name. Then it has a
generic key-value attribute system that allows any backend to expose
its own (namespaced) attributes. (For instance, the local file backend
exposes xattrs and selinux attributes this way.)

GFileEnumerator: enumerates files inside a directory
 
GMountOperation: object that handles the types of callbacks needed
during a mount operation. You create one of these and connect to
e.g. the ask_password signal and then pass it to the mount
operation. When the mount operation needs to ask for a password the
signal will be emitted. There will be a standard implementation of
this in Gtk+ that displays authentication dialogs.

GVfs: Base class for the virtual filesystem. Does mapping to/from
filenames, paths and parse names. This is what gets switched out by
the daemon module.

[...]

GVFS:
====

The virtual filesystem as such is all run in session-wide daemons,
that apps talk to. This has many advantages: state (like caches,
authentication and charset settings) are shared between apps, we avoid
lots of connections to a server, and each app need not directly
link to all the weird i/o libraries needed. Of course, there is a risk
for bloat, but I think we can keep it pretty small by being careful
what the daemons link to.

[...]

A large problem with gnome-vfs is that applications not specially
coded to use gnome-vfs will not be able to read non-local files. A
nice solution to this would be to use FUSE to let such apps use normal
syscalls to access the files. In general its quite tricky to map any
URI to a FUSE file, but with the mountpoint + filename setup gvfs uses
it is very easy to create a FUSE filesystem that lets you access all
the current vfs mounts. 

--8<--


cheers,

Michael