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? _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
