Re: Plans for gnome-vfs replacement

[Dan Winship <danw novell com>]

Cool.

Alexander Larsson wrote:
> At some point in time gnome_vfs_uri_is_local() started detecting and
> returning TRUE for NFS mounts and other type of local network
> mounts. This is both slow and unexpected, and has led to problems and
> unnecessary changes in many places. 

s/TRUE/FALSE/, I think. (gnome_vfs_uri_is_local() used to say that NFS
filesystems were local, now it says they're not.) Are you suggesting
that this behavior is going to go away? It's useful in places as a
heuristic, even if it's not 100% reliable. (Although obviously it's only
useful if it's guaranteed to not hang.)

> As a consequence of the stateful model we don't need the stateless
> properties that URIs has as identifier. To avoid all the problems
> comming from the use of URIs  we use a much simpler form of
> identifier. Namely filenames

We still need to support URIs too at least in some places, because of
'%u' in .desktop files. If GNOME apps switched to using '%f', then
konqueror (and old versions of GNOME) wouldn't be able to pass remote
files to them any more. Likewise, if nautilus/libgnomedesktop didn't
support using URIs for remote files any more, then they wouldn't be able
to pass remote files to KDE apps.

> I imagine all/most actual mounting
> of shares will happen in the file manager and the file selector, or at
> gnome-session startup, so applications don't really need to handle
> this themselves.

Hm... "Recent files" may be on unmounted shares. Or in the konqueror
case above, konq would have the remote fs mounted as a kioslave, but
when it passed the URI to a GNOME app, that app would need to do a gvfs
mount in order to read the file.

> For example, we could be to use "//.network/" as a prefix for the vfs
> filename namespace.

Ew. OK, what's the idea with the fake-paths-instead-of-fake-URIs thing?
As points against URIs, you say:

    1. Using non-standard ones is evil.
    2. gnome-vfs uses broken pathname-handling semantics to make things
       easier for applications.
    3. Escaping and Unescaping is hard, but people want to do it to
       make pretty-looking names.
    4. It makes people think gnome-vfs is more web-browsery than it
       really is.

But (1) also sorta applies to using things that look like file paths but
aren't, (2) seems like it ought to be covered by GFile ("This means you
don't have to do tedious string operations on the pathnames to navigate
the filesystem."), and (3) seems like it's covered by the display name
thing ("These filenames would be ... not really presentable to the user
as is. You'd need to ask for the display name via the vfs to get a user
readable utf8-encoded string for display.").

Another point in favor of paths over URIs might be "you can share the
same representation between gvfs-aware and gvfs-naive apps (if you have
FUSE)", but with the representation you've chosen, you don't even get
that; you have to use a different path when talking to gvfs-naive apps.

For points in favor of URIs, there's the fact that KDE uses them,
various fdo standards use them, and various existing GNOME APIs use them
(eg, the recent files api mentioned before).

So are paths really better than URIs? (I'm totally willing to believe
the answer is "yes", I just don't see it yet.)

> The set of operations on files and folders would be both simplified
> and extended. We'd remove complicated things like read+write access to
> a file, and give less posix-like guarantees...

But:

> We will also write a single gnome-vfs backend that allows access to
> all the glib vfs shares by using a uri like gvfs:///XXX that just maps
> to //.network/XXX. We can also implement a similar backend for kio so
> that kde applications can read and write to the shares.

If gvfs deviates too far from POSIX, then it's the http-method problem
all over again; the gnome-vfs/kio/FUSE modules will have to have hacks
to deal with the non-POSIX semantics of the gvfs filesystem. So the
hacks like write-whole-file-on-close still need to exist somewhere,
although at least you'll never hit them if you use the preferred APIs.

> Furthermore, if FUSE is supported on the system we can write a FUSE
> filesystem so that we can access the files as $HOME/.network/XXX.

Rather than having both a vfs daemon and a FUSE daemon, it seems like it
ought to be possible to squish them both into the same process.
"libgvfsbackend" or whatever would link to libfuse, receive the POSIX
requests from the kernel, make the appropriate not-quite-POSIX gvfs
requests of the backend (via local procedure calls, not dbus), and
perform whatever unfortunate hacks were necessary to get POSIX-like
semantics.

Then the gnome-vfs and kio bridges could also use this more POSIXy
interface (presumably via dbus), so that they could get POSIX-like
semantics too without needing to reimplement the kludges.

And actually, for the more filesystem-like backends (smb, etc), we could
just let the backend implement the POSIX interfaces itself, in addition
to the gvfs ones, to avoid the need for kludges when accessed via
FUSE/gnome-vfs/kio. Then libgvfsbackend would just have default kludgey
methods for anything the backend didn't implement natively...

> I've been doing some initial sketching of the glib API, and I've
> started by introducing base GInputStream and GOutputStream similar to
> the stream objects in Java and .Net. These have async i/o support and
> will make the API for reading and writing files nicer and more
> modern. There is also a GSeekable interface that streams can
> optionally implement if they support seeking.

How do these relate to GIOChannels? Part of why I ask is that
GIOChannels on Windows apparently have issues. (I don't know all the
details, but see Tor's gtk-devel mail from Saturday for an example.)
Someone with Windows clue should pay attention to these APIs to make
sure those problems can be avoided here (if possible).

> However, I think the general architecture is
> pretty sound and in a state where it can be discussed.

Yes, in general, it looks great.

-- Dan