273
edits
Changes
Jump to navigation
Jump to search
Line 40:
Line 40: − − Note: the work for this idea is ''more than halfway done''. The olpcfs2 virtual file system linked below is working, supporting versions and metadata; all you need to do is a UI and an index/searching mechanism on top of that. And even if your indexing mechanism is just brute-force-search each-time, sure, it will be too slow for real use, but we can take it from there, as long you have a working proof-of-concept UI. + +
Development Team/Project Ideas (view source)
Revision as of 13:42, 27 March 2009
, 13:42, 27 March 2009→Versioned Datastore
=== Core Software ===
=== Core Software ===
==== Versioned Datastore ====
==== Versioned Datastore ====
* To add [[DevelopmentTeam/DatastoreRewrite#Versioned_entries_.28not_fulfilled_yet.29|Version support]] for [[Journal]] / [[DevelopmentTeam/Almanac/sugar.datastore.datastore|DataStore]]: Start with (old) [http://wiki.laptop.org/go/Olpcfs Olpcfs] and (newer; less-documented; based on an RCS backend and a relatively small amount of fuse magic) [http://dev.laptop.org/git/users/cscott/olpcfs2/ olpcfs2]. Get Sugar to mount OLPCFS2, a working virtual versioned filesystem, and keep its datastore there. Get datastore to create a new version for each save (automatic or manual). Modify journal UI to use these versions, fork from old versions, etc. Keep with the same name / tags, create a branch if metadata was changed. Allow the user to access "older" versions (Keeping and "old" version will create a branch) and view ancestry (tree of branches).
* To add [[DevelopmentTeam/DatastoreRewrite#Versioned_entries_.28not_fulfilled_yet.29|Version support]] for [[Journal]] / [[DevelopmentTeam/Almanac/sugar.datastore.datastore|DataStore]]: Start with (old) [http://wiki.laptop.org/go/Olpcfs Olpcfs] and (newer; less-documented; based on an RCS backend and a relatively small amount of fuse magic) [http://dev.laptop.org/git/users/cscott/olpcfs2/ olpcfs2]. Get Sugar to mount OLPCFS2, a working virtual versioned filesystem, and keep its datastore there. Get datastore to create a new version for each save (automatic or manual). Modify journal UI to use these versions, fork from old versions, etc. Keep with the same name / tags, create a branch if metadata was changed. Allow the user to access "older" versions (Keeping and "old" version will create a branch) and view ancestry (tree of branches).
We would not expect a GSoC project to be necessarily ready to check into our trunk. For instance, you could avoid facing the issue of automated pruning of old versions for disk space, or not have a converter for existing datastores. However, it should work as a proof-of-concept with a variety of activities.
We would not expect a GSoC project to be necessarily ready to check into our trunk. For instance, you could avoid facing the issue of automated pruning of old versions for disk space, or not have a converter for existing datastores. However, it should work as a proof-of-concept with a variety of activities.
Note: the work for this idea is ''more than halfway done''. The olpcfs2 virtual file system linked above is ''working'', supporting versions and metadata; all you need to do is a UI and an index/searching mechanism on top of that. And even if your indexing mechanism is just brute-force-search each-time, sure, it will be too slow for real use, but we can take it from there, as long you have a working proof-of-concept UI.
*Priority for Sugar: High
*Priority for Sugar: High