gvfs bof notes

[Alexander Larsson <alexl redhat com>]

Here are some short notes from the gvfs bof on saturday at the boston
summit:

First there was some discussion about the problems with the current
gnome-vfs (I missed this part). Then I presented some of the API for the
new gvfs code that I've been working on. The API is centered around the
GFile gobject which represents an abstract pathname, a GFileInfo which
is an abstract form of struct stat in posix, and streams to read/write
file contents. I also sketched out some unfinished ideas of how
non-local file-access will work with separate processes for each
mountpoint accessed via dbus and custom streaming protocols.

We then discussed various issues that need consideration:
* How do we represent icons in the API. We can't reference GdkPixbuf
types (because this is in glib), and just passing filenames might not be
good enough for e.g. remote shares with custom icons. We might need an
abstract icon type.
* How do we handle lockfiles, and do we need them?
* How much of the mime sniffing machinery do we expose to apps.
* Do we want to support looking inside e.g. zipfiles and other
containers. (Consensus: no)
* We need some ui bits for common dialogs in gtk+
* Do we need to expose Volumes/Drives as first level objects in the API,
or is it enough to make GFile expressive enough and use only that
* What part of the gvfs will call gnome-keyring (answer: the mountpoint
daemons)
* We would like to extend the desktop spec and the mimetype spec. The
desktop spec needs a much better way to specify what types of URIs the
apps supports (that can handle pluggable systems). Desktop files and the
mime system should support actions other than "open".

Nathan Holstein has some more detailed notes from the BOF available at
http://isomerica.net/~ngh/vfs_notes.txt

We will probably have another session on sunday or monday. I would like
to get some current users of gnome-vfs to look at the proposed API and
give me feedback on whether it does what they need or not.