[sugar] Remarks on the Work of Sugar

[Marco Pesenti Gritti]

On Wed, Jul 23, 2008 at 1:49 AM, Michael Stone <michael at laptop.org> wrote:
> After mild provocation, Marco and Tomeu asked me to publish some of my
> reactions to sugar's architecture, design, and implementation. Here are
> a few initial comments.
>
> 1) Sugar could better hold contributors if it (and its web presence)
> were designed to be extended and to highlight external contributions.
>
>   Evidence: Trac and xmonad both have thriving communities of
>   contributors based around their plugin architectures and community
>   sites like trac-hacks.org.
>
>   Evidence: Sugar has already attracted new contributors by creating
>   three different extension points:
>
>     Activities themselves
>     Device entries on the Frame
>     Control Panel Entries
>
>   Evidence: Non-extensible aspects of Sugar like activity launching,
>   home view layout, frame contents, and the presence service have
>   stagnated.

We are moving in that direction already. Even the home view layout you
mention has been recently refactored to be easily replaced.

> 2) Sugar would run more smoothly on-XO if jhbuild were retired. By
> running at non-XO speeds, jhbuild permits Sugar developers to retain
> faulty assumptions about the environment in which their code will run.
>
>   Evidence: Sugar uses algorithms which casual inspection reveals to be
>   horribly slow and Sugar has, in the past, suffered from
>   easily-revealed memory leaks which went unfixed for long periods of
>   time in part because developers had little personal motivation to fix
>   the issues.

The memory leaks thing is not true. We started to work on them as soon
as they was reported. Unfortunately the pygtk bindings leaks very
easily.
I agree that we should do more testing and dogfooding on the XO, but I
don't see why should prevent people to hack on Sugar outside the XO.
All our changes goes in joyride very regularly and get tested.

A little automated testing would go a much longer way than getting rid
of jhbuild in this area, ihmo.

> 3) Sugar is built on technologies which encourage excessive layering.
> Excessive layering makes it hard to approach code (high cognitive
> burden) and harms performance (by causing unnecessary data copying and
> by causing data to be stored in the heap rather than the stack or in
> pageable regions of memory.
>
>   Evidence: the "convenience" layers of Python wrappers around
>   dbus-python stubs around dbus objects around two layers of python
>   bindings for an information retrieval system built on a filesystem in
>   merely to create and save files with a dict of attached metadata.
>
>   Evidence: The "convenience" layers of Python wrappers around gobject
>   properties around dbus-python stubs around dbus objects around a
>   hardcoded network manager around the underlying CLI tools and the
>   kernel's netlink sockets.

True. But as Benjamin points out there is a trade off between adding
new features quickly and implement them in the most efficient way.
This is something that we will have to improve radically. I've been
frustrated about the various level of wrappers around the dbus calls
for a while now, but we are not going to be able to address them until
we are required to add features.

>   Evidence: The SVG python icon objects in a three-layer Sugar icon
>   cache spanning gobject properties and cairo surfaces atop gtk and gdk
>   windows atop X windows and pixmaps atop...

Leaving aside the cache issue, that's the normal implementation of a
gtk widget in python, you'd have to switch language or toolkit to drop
layers.

> 5) Sugar is built on technologies that incentivize its developers to
> recompute prior results which could be cached across boots.
>
>   Evidence: Sugar is developed by people running on hardware that is
>   fast enough to recompute results at little cost to interactivity (see
>   §2).
>
>   Evidence: Also, OLPC's shipping JFFS2 implementation does not support
>   writable mmaps or uncompressed inodes.
>
>   Evidence: Python lacks support for loading data without unmarshalling
>   it from bytestreams.

Sure. But again, there is the features/quality tradeoff to consider.

> 7) Sugar prefers IPC techniques with inferior human interfaces (DBus, X)
> to IPC techniques with superior human interfaces (HTTP, 9P, environment
> variables, well-known files, process arguments + status codes + man
> pages).

The heavy use of DBus derive partially from the platform we are using
(GNOME/Freedekstop). The trend there is to increase it's usage and I
don't see how it could not affect us in the future.

Anyway, I agree that in some cases we abused DBus, and the reason is
simply that it was so damn easy. Back to the usual tradeoff... This is
something that will be incrementally addressed.

Marco