[sugar] GVFS, OLPC, and GIT ?
Tomeu Vizoso
tomeu at tomeuvizoso.net
Mon Apr 7 06:56:18 EDT 2008
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
More information about the Sugar
mailing list