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

[Eben Eliason]

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).

Hooray! I agree this is a much needed feature.

> 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),

Yup.

> 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

In all of our preliminary designs, we actually proposed that branches
be flattened from the perspective of the user. That is, the most
recent head of any branch in a tree is the "canonical version" which
appears as the most recent entry in the Journal. I certainly welcome
more thought in the area, but I think that this simplification is
probably the right one, for kids, and with respect to the time-based
nature of the Journal.

> 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

If you look at the designs on the wiki, you'll actually note that the
date in the detail view is a popup.
(http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#12) Our plan
here was to allow selecting a version by choosing the date/time at
which is was created from this popup menu. Additionally, each version
would appear in the list/timeline view of the Journal, so that you
could just as easily scroll "back in time" to several days ago when
you made the first version of a document, and resume that directly
from there.

> 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

I'd probably recommend against this, both because I think there's far
more work to be done to get this working smoothly than you might
think, and because I don't think it's actually an important feature
for kids.

> 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.

This is probably the right decision. I think we need to consider
carefully what metadata gets carried over to new versions, or copies,
of a given object.

Eben

> 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
>
>