[sugar] GVFS, OLPC, and GIT ?

[Tomeu Vizoso]

On Wed, Mar 26, 2008 at 12:16 PM, Alexander Larsson <alexl at redhat.com> wrote:
>
>  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.

You have just described the current API:

http://wiki.laptop.org/go/Activity_DBus_API#Datastore

The argument being made is that exposing versioning and metadata
through the old path-based operations in POSIX would be a better API
because of compatibility with current code and an API already known by
developers.

I'm still not decided one way or the other, I would like to see first
how existing and new activities would interface with the new DS
through the new path-based API.

Thanks,

Tomeu