Data Storage and User-facing System Requirements [was Re: [sugar] 9.1 Proposal: Files]

Erik Garrison erik at
Fri Oct 31 11:16:11 EDT 2008

On Thu, Oct 30, 2008 at 03:09:16PM -0400, Benjamin M. Schwartz wrote:
> Hash: SHA1
> Erik Garrison wrote:
> > It seems from my reading of mailing lists, IRC logs, and listening to
> > conversations with people that we are trying to resolve all of these
> > issues by implementing more code to get around difficulties imposed by
> > our current data storage implementation and security model.
> > 
> > My argument is that we can do less work and get an improved result from
> > the user's perspective by removing the layers of code (datastore and
> > security restrictions) which prevent applications from behaving as they
> > normally do on other systems.
> Erik:  If you want applications to behave as they do on other systems,
> then why not just use an other system?
> I am not being facetious, and I hope I don't seem disrespectful.  If you
> are not interested in Sugar's goal of rearchitecting the computer
> experience to optimize for our students, then don't use Sugar.  It sounds
> to me like your goals would be achieved, for example, by running Andres's
> debxo-LXDE or the Fedora XO spin, perhaps with minor UI customizations.

Sugar is far more than its data storage system and a security model.  It
is a community of people trying to build a very usable computing
environment specifically geared toward use in an educational setting.  I
think that this community should continue; I don't want to derail it!  I
want to help it be more effective at its core goals.

If writing our own data storage systems and upstream-incompatible
security models frustrates the fundamental things that Sugar wants to do
(among which I believe lie the requirements which I listed), then we
should reconsider devoting resources to such tasks.  I think there is
ample evidence that this is the case.

> Sugar is not nearly finished, but it is headed for a realm of new
> features, including an entirely new metaphor for stored data.  You seem to
> be proposing that we stop that development process because our current
> betas (Sugar is still in beta) are not up to the quality of mature
> systems.  This upsets me.  Please don't derail this train just because it
> has not yet reached its destination.

I don't think we should be coupling important features of computer use,
such as data storage and retrieval, to systems that are relatively
untested or still under heavy development and design.  By making the
datastore and Journal lynchpins in the system we have caused serious
issues for users.  There are small changes we can make to the system
design which resolve this issue by decoupling data browsing and data
storage.  The obvious system to use is the underlying POSIX filesystem.

That said, I can find no clear reason why the unique work which we want
to do cannot happen on top of such a stable base layer.  Why does the
use of files preclude the Journal and our unique metaphor for stored


More information about the Devel mailing list