[sugar] GVFS, OLPC, and GIT ?

[Benjamin M. Schwartz]

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 ;-)

To be clear, my disappointment is in fact that GVFS is not high-level
enough.  It seems to me that a path-based filesystem API is not
appropriate for a versioning datastore, because the versioned objects
themselves contain path trees, leading to ambiguity about the meaning of
a path.  This goes double when both versioning and complex metadata are
present.  I would prefer something much more like a typed OO interface.
Indeed, that is what we have now: an object-oriented DBus API.  That
still seems like the best solution to me.

Also, GVFS does not depend on libgnome.  Even if it did, I would not
consider that immediately inappropriate for the XO.  We are free to
impose any dependencies we like on Sugar, so long as they are useful.
The goal of GIO/GVFS is to "provide an API that is so good that
developers prefer it over raw POSIX calls".  I am taking them at their
word.

> 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.
> 
> I expect GVFS to work well for file copy, move and for basic file
> viewers, not for a real read/write application.

Are you sure?  The GIO streaming interface includes a number of
memory-like data transfer methods.  I have not reviewed them carefully.
(http://library.gnome.org/devel/gio/unstable/streaming.html)

> >  |> What would you do, if you were trying to provide a version-controlled
> >  |> datastore as a desktop service?
> 
> Hmmm. See my notes here in a somewhat similar discussion -
> http://lists.laptop.org/pipermail/devel/2008-March/012047.html

I agree with that assessment and proposal.  However, it only works for
non-versioning aware applications.  I am looking for a complementary API
that provides an application (e.g. the Journal) with a clean API for
managing the entire version history.

> Look at git-fuse.

I will.  GVFS and FUSE are entirely comparable, I think, and what I was
wondering about is very much like a GVFS analogue of git-fuse.

--Ben