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