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. 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 _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
