Difference between revisions of "Version support for datastore/Proposal"

From Sugar Labs
Jump to: navigation, search
(change UI for first prototype, mention metadata handling)
(fill in anything except the timeline)
Line 1: Line 1:
Note to self: Need to apply at [http://socghop.appspot.com melange, google's web app], too till 19h UTC.
 
 
 
{{TOCright}}
 
{{TOCright}}
  
Line 11: Line 9:
 
* Name: Sascha Silbe
 
* Name: Sascha Silbe
 
* Age: 29
 
* Age: 29
* EMail: user silbe, domain sugarlabs.org
+
* EMail: domain sugarlabs.org, user silbe (obfuscated for SPAM reasons)
 
* Wiki user name: sascha_silbe
 
* Wiki user name: sascha_silbe
 
* IRC nickname: silbe
 
* IRC nickname: silbe
Line 18: Line 16:
 
* Work hours: about 12h to 00h local time, i.e. 10h to 22h UTC
 
* 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: [http://husky.sourceforge.net/ Husky (Fidonet on Linux)] (many years ago, co-founded the project; my profile on that page is rather outdated), [http://www.openstreetmap.org 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).
 
* Open source projects (with other developers beside me) I participated in: [http://husky.sourceforge.net/ Husky (Fidonet on Linux)] (many years ago, co-founded the project; my profile on that page is rather outdated), [http://www.openstreetmap.org 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).
 +
* Current affiliation with SugarLabs: maintainer of the [[DevelopmentTeam/Buildbot|build infrastructure]]
  
 
==About my project==
 
==About my project==
Line 59: Line 58:
 
=== Time line ===
 
=== Time line ===
  
 +
(to be completed)
  
 +
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
  
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,  
 
The Summer of Code work period is 7 weeks long,  
 
May 23 - August 10;  
 
May 23 - August 10;  
Line 89: Line 85:
 
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.
 
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
+
-->
 +
 
 +
== Me and the community ==
 +
 
 +
=== Action after getting stuck ===
 +
 
 +
For this project, getting stuck means needing advice on UI issues. As I can ask both the whole [[Design_Team|Design Team]] and a friend of mine for input, it's rather unlikely that nobody will be around for a significant amout of time. Also I don't see the code produced by this project as the one and only answer to the problem, but rather as a start of a process. So I could just do an arbitrary choice and continue with the project, it's still adaptable later.
  
*Coolness factor:++
+
=== Impact of this project ===
  
*Difficulty: Hard
+
One of the initial design goals will actually be provided. Instead of giving users the choice of irrevocably deleting either the
 +
old or the new content upon exit as current desktop applications do (unless the user explicitly invokes a "Save As" operation
 +
prior to exit), the computer will now retain both and provide the user with ways to access them.
  
*Skills needed: primarily Python UI (pygtk); also FUSE/file systems (this part is mostly done); and Packaging and building.
+
=== Sugar Pilot ===
 
 
  
==You and the community==
+
While I would very much like a Pilot to occur in my vicinity (once both this project and the Rainbow support have been merged),
 +
I'm not yet sure what the best target would be as I'm not directly involved with any school.
  
# 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.
+
=== Keeping the community updated ===
# 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?
+
 
# What will you do if you get stuck on your project and your mentor isn't around?
+
For regular updates, I'll probably update a wiki page, as those interested in it can subscribe and get notifications via email.
# 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?
+
There are going to be several projects going on, so sending the reports to the regular mailing lists feels like spamming.
 +
For problems and questions, I can use both the IRC channel and the mailing lists, depending on the exact nature and target
 +
audience (e.g. details on the current data store are best asked on IRC, while UI design questions are best elaborated in
 +
a mail thread where there's sufficient time to do research to back up arguments).
  
 
==Miscellaneous==
 
==Miscellaneous==
[[Image:New-developer-challenge.png|thumb|right|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.]]
 
# We want to make sure that you can set up a [[DevelopmentTeam#Development_systems|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.
 
# What is your t-shirt size? (Yes, we know Google asks for this already; humor us.)
 
# Describe a great learning experience you had as a child.
 
# 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 [http://dev.ryzom.com/projects/nel/wiki/GSoC2009WritingProposals 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.
+
I'm skipping the screenshot of the simple text replacement task for time reasons. I guess being the maintainer of the
 +
[[DevelopmentTeam/Buildbot|build infrastructure]] and having committed several patches on the bugtracker should be
 +
sufficient substitute. :)
 +
 
 +
* T-Shirt size: depending on the actual size (instead of just what's printed on the label) it's M up to XXL. Usually I go for L.
 +
=== Great learning experience as a child ===
 +
Wow, good question. I don't remember any particular event right now. In general, I learned most (and most easily) when I was
 +
actually doing something, without any external help. Reading books (even text books, though not the school ones) was fun as well and
 +
helped me get further insight and new ideas. That's still the case, though "the internet" has replaced books for me.
 +
 
 +
=== Anything else to like the project more ===
 +
 
 +
I don't think there's any need for raising the priority of this projects even higher, but as you asked I'll give a reason nonetheless:
 +
Working on this project will significantly increase my understanding of the data store, the Journal and the whole Glucose software
 +
stack. As a result, [http://dev.sugarlabs.org/ticket/593 adding Rainbow support] is going to get a lot easier.
 +
 
  
 
[[Category:2009 GSoC applications]]
 
[[Category:2009 GSoC applications]]

Revision as of 15:12, 2 April 2009


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: domain sugarlabs.org, user silbe (obfuscated for SPAM reasons)
  • 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).
  • Current affiliation with SugarLabs: maintainer of the build infrastructure

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 the current Journal view by adding previous/next buttons to the details view of each entry 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". Metadata is going to be part of each version (and mutable without creating a new version) at first.

Rationale

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

(to be completed)

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


Me and the community

Action after getting stuck

For this project, getting stuck means needing advice on UI issues. As I can ask both the whole Design Team and a friend of mine for input, it's rather unlikely that nobody will be around for a significant amout of time. Also I don't see the code produced by this project as the one and only answer to the problem, but rather as a start of a process. So I could just do an arbitrary choice and continue with the project, it's still adaptable later.

Impact of this project

One of the initial design goals will actually be provided. Instead of giving users the choice of irrevocably deleting either the old or the new content upon exit as current desktop applications do (unless the user explicitly invokes a "Save As" operation prior to exit), the computer will now retain both and provide the user with ways to access them.

Sugar Pilot

While I would very much like a Pilot to occur in my vicinity (once both this project and the Rainbow support have been merged), I'm not yet sure what the best target would be as I'm not directly involved with any school.

Keeping the community updated

For regular updates, I'll probably update a wiki page, as those interested in it can subscribe and get notifications via email. There are going to be several projects going on, so sending the reports to the regular mailing lists feels like spamming. For problems and questions, I can use both the IRC channel and the mailing lists, depending on the exact nature and target audience (e.g. details on the current data store are best asked on IRC, while UI design questions are best elaborated in a mail thread where there's sufficient time to do research to back up arguments).

Miscellaneous

I'm skipping the screenshot of the simple text replacement task for time reasons. I guess being the maintainer of the build infrastructure and having committed several patches on the bugtracker should be sufficient substitute. :)

  • T-Shirt size: depending on the actual size (instead of just what's printed on the label) it's M up to XXL. Usually I go for L.

Great learning experience as a child

Wow, good question. I don't remember any particular event right now. In general, I learned most (and most easily) when I was actually doing something, without any external help. Reading books (even text books, though not the school ones) was fun as well and helped me get further insight and new ideas. That's still the case, though "the internet" has replaced books for me.

Anything else to like the project more

I don't think there's any need for raising the priority of this projects even higher, but as you asked I'll give a reason nonetheless: Working on this project will significantly increase my understanding of the data store, the Journal and the whole Glucose software stack. As a result, adding Rainbow support is going to get a lot easier.