On Wed, Mar 26, 2008 at 12:16 PM, Alexander Larsson <[EMAIL PROTECTED]> 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 > > > <[EMAIL PROTECTED]> 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 _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar