Module proposal: gio and gvfs for gnome 2.22?

[Alexander Larsson <alexl redhat com>]

I've been working on gvfs and gio for a while, and its starting to reach
some minimal level of maturity. I'm currently working on porting
nautilus from gnome-vfs to gio in order to verify that the design works
and so that we can fix any problems or bugs. It might also be
interesting for other applications to try it out. 

I believe its possible to get this into shape for Gnome 2.22, so maybe
we should start a discussion about this. Let me give a short
introduction to it for people who haven't followed the development.

"gio" is a gobject-based library that abstracts out various forms of
I/O. The long term plan for it is to be part of glib, like libgthread or
libgobject. However, to avoid having to branch glib and to make it easy
for applications to use before its merged into glib it is currently
availible in the "gio-standalone" repository in gnome svn.

Here is what libgio currently contains:

* Basic input and output stream base classes. 
  These allow both synch and async i/o and is a basic API that many
  types of streams can implement. Having an api like this at the low
  level means you can easily connect code from separate modules.
* Concrete implementations of streams: local files, sockets and
  memory buffers.
* Streams working on other streams: Buffering, data parsing/writing
* GFile - a filename abstraction
  This is a object that represents something "like" a filename path (but
  its extensinble so it could be a uri or something different too). It
  allows you to do all the typical file operations that desktop
  applications need.
* An implementation of GFile for local files
* APIs for various things needed for file handling:
   api for cancelling i/o operations
   content types
   icons
   app info (mimetype->app mapping and opening files with an app)
   basic volume monitor (for listing volumes in e.g. file selector)
   file and directory monitoring (fam/gamin/inotify/polling supported)
   
libgio has no hard dependencies apart from glib. It can optionally use
various libraries (fam/gamin for file monitoring, libhal for volume
monitoring, libxattr/libselinux for some file info details), but these
are not exposed directly in the API. Also, some of them will be
converted to modules so that they can be picked up correctly at runtime
as needed.

In fact, libgio is designed to separate out dependencies by allowing
apps to depend on abstract APIs, and then letting various
implementations fill in these APIs.

GVFS is one such implementation, availible in the "gvfs" module in gnome
svn. It is a "userspace vfs", similar to gnome-vfs, which plugs into
gio. Its shipped as multiple parts:
1) A client library
  This is a GModule that gets loaded by libgio and implements GFile and
  the other stuff required to allow files to be accessed and
  maninpulated. This library only depends on dbus which is used to talk
  to daemons on the session bus handling the actual i/o protocols.
2) A main gvfs-daemon
  This daemon registers with the session bus and keeps track of all
  mounted locations and lets you mount new ones.
3) A horde of mount-daemons
  Each mounted location is handled by a separate daemon. This protects
  against instability in other mount daemons, and it makes it easier to
  implement backends (as they fully control their context).

There is also an optional fuse module, so that on systems supporting
fuse we can let 3rd party applications not using gio access the mounted
gvfs filesystems.

Last week I created the nautilus "gio-branch" branch where I've started
work on converting nautilus to use the gio apis. Its not yet in a state
where is useful, but there is progress.

For more details about gvfs and gio here are some references:

Slides from my guadec presentations:
http://blogs.gnome.org/alexl/2007/07/20/gvfs-presentation-slides/

Mails from me about gvfs:
http://mail.gnome.org/archives/gtk-devel-list/2007-September/msg00012.html
http://mail.gnome.org/archives/gtk-devel-list/2007-February/msg00062.html
http://mail.gnome.org/archives/gtk-devel-list/2006-September/msg00072.html

So. What is the plan for Gnome 2.22?

I'm not sure exactly how this plays out, but it would be nice if we
could get something in. Although gio is now shipped separately it is
meant to be in glib, and the release schedule for glib is normally tied
to gtk+, which isn't planned to release a new version next summer or so.

However, mattias has hinted about the possibility of doing a glib
release earlier than that to get gio out. Ideally there are some common
ui things related to gio that should be in Gtk+ (progress dialogs,
password dialogs, etc), but perhaps we could do these in a libeel
fashion in the first round.

I'd like to hear peoples thoughts here. gio and gvfs aren't yet at a
state where its expected to "just work" (not much tested, little docs,
etc), but I'm planning to fix that. It would be nice if we could replace
gnome-vfs with a more modern API at the right place in the stack as
early as possible.

So, does it make sense to add gio (standalone or in an earlier glib
release) and gvfs to the Gnome 2.22 desktop module set?