[Sugar-devel] GSoC proposal: version support for data store and Journal

[Tomeu Vizoso]

Hi Silbe, first of all congrats on the proposal and second sorry about
the topposting.

What if your GSOC application focuses on the backend (datastore) and I
do the modifications needed in the UI?

The design team at OLPC (most of it are active contributors at SLs)
had thought quite a bit about how to expose it to the user and we even
had a prototype working on the first DS just before the first
"production-ready" version of Sugar was released.
At that point was decided that the versions work was too immature to
release and was put into the drawer, then the DS contract finished and
OLPC didn't paid again anyone to work on the DS so it entered in
maintenance mode until now (except the little time I managed to put
into it).

With this I mean that we currently have in SLs pretty good knowledge
of what needs to be done and we miss only someone talented that can
put a few months full-time on the backend. How does it sound?

Regards,

Tomeu

2009/4/2 Sascha Silbe <sascha-ml-ui-sugar-devel at silbe.org>:
> Hi!
>
> As my diploma thesis got delayed again, I decided to apply for GSoC and
> implement #1 on my list of most urgent missing features in Sugar: Version
> support (sorry Michael, but Rainbow only got second place on that list).
>
> The proposal is up on [1]. Feedback welcome (as always), both on the
> proposal and on the final (i.e. non-GSoC) UI design. While the GSoC project
> is only about a prototype with a limited UI, it doesn't hurt to start
> thinking about what it should become later. This is actually the hardest
> part for me: While I have strong opinions about how it shouldn't work and
> some ideas how it should, I actually don't know what design a regular user
> would understand best (or at all).
>
>
> Copy of "2.1 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.
>
>
> PS: Special thanks to Ben and Homunq (?). You provided great feedback
> (especially on issues where we disagree), I'm looking forward to
> pestering...I mean, discussing future more-or-less high-level design
> decisions with you. :)
>
> [1] http://wiki.sugarlabs.org/go/Version_support_for_datastore
>
> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQEcBAEBAgAGBQJJ1SyCAAoJELpz82VMF3Da+UQIALFPqNr3XVnSGXLvpJrR737K
> /VOmWMyb5NCobjMJbGWcyjlDfCRlQs7tZwWOsp6v30ksrx2N5KaanEiBo0ix3I6R
> cjAzWl3UJ7JxhPoCSz07lP8BDXYi3lqSdf60Itk4H5xTH2wlYcgkQ5xvh+XMtlcn
> kdUkR9PhC4s+BQ+fhnm2eSjuwrAwDH7TdnqHVGOJrBSCEZ+QSMlQlHP+U/GcaSpu
> 42iC7QDyASwMzVYPQIHCl/U2/nuUj0H/k0V8pmZl5+qSy3PRMIoJqB4aI5QsyS7O
> 5RTmK93JBuxztQ//F9KN4HA3H18jCaXVnmuXyi1gsnr+xYVB6Gw+WfJqSMqqiOY=
> =JTVX
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>