[sugar] GVFS, OLPC, and GIT ?

[Alexander Larsson]

On Tue, 2008-03-25 at 16:27 -0400, Benjamin M. Schwartz wrote:
> 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.

I agree that a path based filesystem is not the ideal for a versioned
datastore. However, it may be useful as a *view* of such a datastore for
applications that are not programmed against the (likely very different)
API of the data store. 

However, as the olpc project has much more control of the software
running on the laptops you might be able to only ship software that uses
the native datastore APIs.

A "native" API for a versioned datastore should probably make away
completely with filenames, instead use some autogenerated unique
identifier like uuids, have document type specified in the file creation
operation and allow specifying which version fork to open in the open
content stream call. This is interesting in its own, but not the goal of
gvfs, the gvfs goal is more like allowing access to the path-based file
stores that already exists and where users have files stored.