[Sugar-devel] Hypothetical sugar-0.90 material, draft 1.

[Martin Langhoff]

On Thu, Jun 10, 2010 at 1:41 PM, Benjamin M. Schwartz
<bmschwar at fas.harvard.edu> wrote:
>>  - Reworking the datastore... while I welcome efforts in a new
>> datastore... _every Sugar release has a new DS implementation_ and
>> they get little testing and I've seen extremely light thinking about
>> what is _actually_ needed.
>
> That's a very polite way of saying that you disagree with the extensive
> thinking that's been done about datastore design and implementation for

No. _It says exactly what it says_. People have been thinking lots
about the fun part of the problem, thinking superficially about what
they'll have fun implementing. Not about the complete problem space.
Not about what hits users. Not about what we need for a saner
implementation.

> even just a list of use cases that you believe have been
> overlooked.

Ah...

 - ENOSPC?
 - Backwards compatibility? (Horrendously broken ATM on 0.84 -- I have
a bad patch for that...)
 - Integration with GNOME? (for those "dual desktop" OS builds)
 - Some reasonable degree of atomicity?
 - Sensible backup/restore?
 - Smarter handling of "bundle" filetypes...
    = so together with the Journal, it can expose the many images or
videos in a 'Record'
    = so the Record "file format" gets untangled
 - Re-thinking of the Journal / Datastore interactions to access the
normal filesystem so that Gnome's ~/Documents directory can be browsed
 - Working gracefully with large files

> Do you think our current datastore meets your criteria?

No. It has heaps of problems.

And I love some the cool ideas (git-like smarts for example). But
_first_ DS has to shed its current stupidities. Talk of a rewrite that
lists cool ideas but none of the big gaps gives me the CADT shakes.

Just in case, I am taking
http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/blobs/master/datastore-redesign.html
to be Sascha's plan. Hope that's the right one.

Hate to sound so cranky, and I honestly like a VCS-styled Journal/DS.
But there are many hard problems to solve in the Journal/DS, and many
added hard problems that come with the VCS. Ignoring the hard problems
and charging with the features won't help a bit.

cheers,


m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff