[sugar] GVFS, OLPC, and GIT ?

[Alexander Larsson]

On Tue, 2008-03-25 at 15:46 -0400, Martin Langhoff wrote:
> On Tue, Mar 25, 2008 at 10:29 AM, Benjamin M. Schwartz
> <bmschwar at fas.harvard.edu> wrote:
> >  |> sufficiently generic to encompass multiple versions.  I do not fully
> >  |> grasp the layering between GIO and GVFS.
> 
> Be aware that GIO/GVFS are very high level. In other words, they work
> for the Gnome guys because they don't realise that not all the world
> links to libgnome ;-)

gio/gvfs doesn't link to anything but glib, dbus and hal on the client
side.

> zip and tar and rsync and amanda won't work with them. Any modern
> program will break trying to use a GIO/GVFS "mount" as their location
> of storage. Moderately modern interfaces like mmap - that you need to
> work on advanced filehandling, for example in image manipulation
> programs - don't work either.

GVfs does contain a fuse filesystem implementation that allows posix
apps to access the mounted gvfs filesystems, but you're right that the
full extent of the posix semantics are not availible in the gio APIs.
This is very much by design, as many of the features of posix are just
unimplementable on the backends that we want to support. 

Furthermore, some of the features posix give you to implement certain
highlevel operations do not match other backends, even if there are
features availible that allow you to implement the desired highlevel
operation in some other way. For instance, you want a highlevel "save"
operation that implements atomic safe file overwrite (to the extent
possible). On posix this is implemented via O_EXCL open of tempfile and
then relying on atomic replacement of rename()[1]. However, this just
doesn't match how things like ftp and webdav work, but they have other
ways to implement this operation. Thus gvfs has a highlevel operation
for this with backend-specific implementations.

Of course, the goal of gio/gvfs is not to replace all file access. It
would make no sense to implement e.g. a database over it, and neighter
would it make sense to use for application data files or internal
implementation details. Its goal is to be used for what I call "user
document" files. This doesn't mean they have to be word processor
documents, just the kind of files the user produce and consume during
his normal work.

If your "modern" application expects to be able to mmap something and
get the behaviour you generally expect from mmap that means that then
app (by design) can't ever e.g. directly work on a file on an ftp server
(in any sane way). Thats a design choice of the app author, although he
could of course use gvfs to download the file and then work on it
locally.

> I expect GVFS to work well for file copy, move and for basic file
> viewers, not for a real read/write application.

It depends on what you mean by a "real" application of course. The main
usecase is for applications that use a load/save document model where
the entire document is streamed into memory.

> >  | * Have some kind of operation that takes a versioned filesystem mount
> >  | (globally) to a different version.
> 
> Look at git-fuse.

fuse is inherently path based too and has no notion of versions, so its
not any different from gvfs in this respect.

[1] Well, this is a simplification of the posix save code, as its really
quite a bit more complicated, but you get the point.