[Community-news] on splitting Sugar

[John Gilmore]

> > That said, Sugar needs to
> > be disentangled. I keep using the omelet analogy, claiming it needs to be a
> > fried egg, with distinct yoke and white, rather than having the UI,
> > collaborative tools, power management and radios merge into one amorphous
> > blob.
>
> My understanding is that the Sugar UI is composed of inseparable
> components because we wanted to give an integrated and coherent
> experience. In which way are you suggesting to split Sugar?

It's possible to provide a coherent experience by coordinating work
among several projects, rather than by forcing all the work into a
single "take it or leave it" project.

Some of the work below is already done, some is agreed to, some may
never be done.  Here's my take on the fracture lines on which to
shape the diamond of Sugar:

The collab framework should definitely be split, so that apps that run
on any GUI can collaborate (with apps that run on their own GUI or on
another).

The window manager ("shell") should be split from the application
toolkit.  This is a fairly small job, but nobody's done it.  Right
now, Sugar apps don't run on other window managers (they lack icons),
nor do they work across a TCP connection (like every other X
application) because the Sugar shell is looking *in its own local
filesystem* for the application's icon.  There appear to be other
problems, which are easy to reproduce by setting DISPLAY on your OLPC,
pointing it to any Linux machine that runs X, and then trying to start
a Sugar activity.  Similarly, it should work cleanly for an ordinary
Linux app to be displayed remotely on an OLPC screen.  This is the basic
promise of X, but small dumb bugs break it currently.

The Sugar file system ("datastore / journal") is in my opinion a major
mistake, and should be separated from the application toolkit.  There
are good reasons that hierarchical filesystems rather than
blog-structured journals (or more complex databases) are the norm on
every major OS.  Apps should be able to use a standard "file open
dialog", and get the journal on OLPC, while the same source code gets
the Finder/Open Dialog Box on MacOS, for example.

The presence implementation only works on access points and on meshes --
but not on non-meshed, ad-hoc 802.11.  The vast majority of computers
with 802.11 don't have mesh, but they would benefit from being able to 
"see" nearby laptops and share applications with them (whether or not
a local access point, or global Internet access, is working).  For full
integration, this probably requires some driver work, but most of the work
is probably at a daemon and library level.

These are the four major axes I see refactoring Sugar along.

	John