Version support for datastore/Proposal

Note to self: Need to apply at melange, google's web app, too till 19h UTC.

Please note that this proposal isn't fully fleshed out because I decided to apply only last minute (my diploma thesis would have been within the same time frame originally, but got delayed for external reasons so I can participate now). A proper design will be the first part of the project, see the time line given below. The issues and possible solutions are well-known and the scope is sufficiently limited to ensure this project will be a success.

About me

• Name: Sascha Silbe
• Age: 29
• EMail: user silbe, domain sugarlabs.org
• Wiki user name: sascha_silbe
• IRC nickname: silbe
• Primary language: german
• Location: Germany
• Work hours: about 12h to 00h local time, i.e. 10h to 22h UTC
• Open source projects (with other developers beside me) I participated in: Husky (Fidonet on Linux) (many years ago, co-founded the project; my profile on that page is rather outdated), OSM, contributed bug reports and patches to a large number of projects. Try a web search on my name, it's unique (AFAIK at least).

About my project

• Name of project: Version support for data store / Journal
• Technologies used: The ones currently in use by the data store / journal. The bonus part might introduce additional ones (e.g. sqlite) for indexing.

Description

Don't overwrite existing entries in the Journal with the same name (which currently means loosing the old content forever and happens automatically), but rather add a new version to the entry. Enhance the UI to allow easy (and simple to understand) access to "old" versions, including modification (which means automatically saving in a new branch). As "easy and simple to understand" isn't actually easy to implement, I'll concentrate on enhancing (by listing each version separately) the linear, time-based view of the current Journal design for the primary part of the project. Adding a version tree details view and possibly other ways of presenting versions are planned for the optional (based on remaining time) "bonus part".

Version support for data store / Journal already was part of the original design concept for the Journal, but hasn't been finished yet.

There are several prototypes (Olpcfs, olpcfs2) that try to not only introduce version support, but also compatibility with legacy (i.e. non-Sugar) applications and, in the case of Olpcfs, support for the activity-based view. While those designs (and partial implementations) are quite interesting from a research point of view and might prove useful later on, the issue of legacy application compatibility is a rather large can of worms, esp. if the applications are supposed to have access to multiple versions (there are other issues as well, e.g. treatment of multiple files written by the same application, deletion, handling of file names and file types).

For this reason, I don't believe that any of these prototypes will mature enough to get integrated in Sugar even mid-term. My project focusses on the version support instead, enhancing the current data store instead of replacing it, with the Journal as the only intended user of the versioning API (though, at least in theory, regular activities could access it as well).

The details of the project (i.e. on-disk format, exact API and UI design) needs to be considered with the Development Team resp. Design Team, but the general approach is quite clear.

Time line

Note: remaining part of proposal needs to be written (below are just notes and copies from the template page).

(to be written)

2009-04-12: Easter 2009-04-20: start of (university) term 2009-05-23: start of GSoC 2009-07-06: GSoC midterm evaluation ("working and 90% done") 2009-07-25: end of (university) term 2009-08-10: end of GSoC

The Summer of Code work period is 7 weeks long, May 23 - August 10;

1. Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described.

This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant. 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.

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

• Coolness factor:++

• Difficulty: Hard

• Skills needed: primarily Python UI (pygtk); also FUSE/file systems (this part is mostly done); and Packaging and building.

You and the community

1. If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.
2. Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?
3. What will you do if you get stuck on your project and your mentor isn't around?
4. How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?

Miscellaneous

An example of the kind of screenshot of your first modification to your development environment which you should include in your application. Note that the drop-down menu text has Mel's email address in place of the word "Restart" - your screenshot should contain your email instead.

1. We want to make sure that you can set up a development environment before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.
2. What is your t-shirt size? (Yes, we know Google asks for this already; humor us.)
3. Describe a great learning experience you had as a child.
4. Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?

The NeL project has some good general recommendations for writing proposals. We endorse them all; although Sugar is (regrettably) not test driven development (yet - your project could change that!), we encourage GSoC code to include tests.