Re: [sugar] GVFS, OLPC, and GIT ?
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
Re: [sugar] GVFS, OLPC, and GIT ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander Larsson wrote: | On Mon, 2008-03-24 at 15:34 -0400, Benjamin M. Schwartz wrote: | Dear Mr. Larsson, | My name is Ben Schwartz, and I am a volunteer with OLPC. As you may be | aware, the OLPC design calls for a centralized versioning differential | datastore, in which all of the user's work is kept. The versioning | requirements are similar to the capabilities of git, so git, or a | similar version control system, might be used as the backend. | | In addition to versioning, OLPC also requires that objects in the | datastore support extensive metadata for tagging and commenting. | | Would GVFS be an appropriate layer in which to implement generic access | to a version-controlled storage system like git? In my perusal of the | GIO API docs, it was not clear to me that GIO's notion of a file is | sufficiently generic to encompass multiple versions. I do not fully | grasp the layering between GIO and GVFS. | | GIO is the API. It is used by applications to access, enumerate and get | info about files. It models the filesystem as an abstract entity that | has a behaviour somewhat similar to posix, but more generic, with some | extended operations (copy file, save, etc), and with somewhat less | strict semantics. It contains an implementation of this for local files, | but also allows plugins to extend this functionallity. | | GVfs is a plugin for gvfs that allows support for access to non-local | files. This is achieved by a model where each mount of a remote (or | otherwise virtutal) location is handled by a daemon. The gio plugin uses | dbus to inititate operations with the daemon. GVfs also contains a set | of backend daemons for different types of mounts (ftp, dav, sftp, etc). | | What would you do, if you were trying to provide a version-controlled | datastore as a desktop service? | | The gio file model is somewhat generic. For instance file metadata are | namespaced key-value pairs that you can extend however you want, and the | backing of your filesystem can be whatever. However, it doesn't really | have explicit versioning support. So, reading files from the latest or a | particular snapshot in history of a versioned filesystem is handled | fine, but the actual operations related to versions are not naturally | expressed. | | However, it certainly can be done in a variety of ways. Some options off | the top of my head are: | | * Mount the specific tree version you want (or HEAD to follow latest) as | a separate mount (off the same backing version store) | | * Have some kind of operation that takes a versioned filesystem mount | (globally) to a different version. | | * Expose multiple versions of the same file/directory using different | names. For example each directory could have a .history subdirectory | with files like .history/filename/version which is a historic | version of filename. | | What kind of user interface are you expecting to have for this? A | timeline/time-machine kind of browser, or a per-file open-old-version | kind of thing? The desired UI is something like this: http://wiki.laptop.org/go/Designs/Journal There are large number of different, independently revision-controlled directories, but the user can select any item and look through previous versions of it. I think there are also plans for a more detailed time-line exploration view, but I do not know if any details have been drawn yet. It sounds like in order to use GVFS for a revision-controlled system, one must either represent versions as paths or mounts. Neither seems ideal to me, as versions are something else altogether. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH6Qw/UJT6e6HFtqQRAtcGAKCSr4WQmfMSxiuHkRezkdDGe2rBEQCeKa+8 fnWEU36rSJkHvN4/RIZWzws= =Tote -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] GVFS, OLPC, and GIT ?
On Tue, 2008-03-25 at 10:29 -0400, Benjamin M. Schwartz wrote: It sounds like in order to use GVFS for a revision-controlled system, one must either represent versions as paths or mounts. Neither seems ideal to me, as versions are something else altogether. Exactly. Its doable, but not native to the API. Versioned filesystems like that isn't yet a well known problem space, so I'd hesitate to put in an untested solution into the stable glib APIs. At some point they may get added though. Of course, even if you don't use gvfs for modeling the file system you can still reuse large parts of the gio apis. For instance stream interfaces, the async i/o models, and the cancellation system. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] GVFS, OLPC, and GIT ?
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 ;-) 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. | 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 | * Have some kind of operation that takes a versioned filesystem mount | (globally) to a different version. Look at git-fuse. | * Expose multiple versions of the same file/directory using different | names. For example each directory could have a .history subdirectory | with files like .history/filename/version which is a historic | version of filename. I think git fuse also has similar ideas. cheers, martin -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
