[sugar] Write needs your help (was Re: Programming environments on the XO)

[Erik Garrison]

On Thu, Jul 17, 2008 at 10:16:07AM +0200, Tomeu Vizoso wrote:
> If we cannot bring all the abiword potential to Sugar's Write, we risk
> someone will start asking for running unsugarized OpenOffice or
> Abiword on the XO, just as happened with Browse :/

Given the quantity of free software available for Linux distributions
relative to the quantity of available sugarized applications, I believe
that repeats of this pattern will be inevitable.

As I understand, there are a variety of problems with the use of
unsugarized applications:

    - UI issues because of high screen dpi and small size.
    - Journal integration.
    - Resource utilization.
    - Bitfr?st and security concerns.
    - Collaboration.

I expect there are others and would be happy to know them so that I
better understand this problem.

-------

By simplifying Journal integration and collaboration, the following
steps might improve our ability to support unsugarized apps without
sacrificing much in the way of user experience.


To simplify Journal/datastore integration:

 *) Remove the Bitfr?st application isolation scheme or modify it such
that Activities could write to arbitrary locations in which the olpc
user has write permissions.

  This would allow unsugarized activities to write to places they (as
Linux apps) expect to be able to write, such as /home/olpc/ (e.g.  for
configuration settings and saving user files).

 *) Make the Journal a watcher and indexer instead of a gatekeeper to
the user's data so that applications no longer need to be ported to
write data and metadata via the datastore API.

  We could use inotify(7) to add a watch to the user's home directory.
The watching application (Journal) could hold a table of typically used
files -> Activities / applications.  We would still require work to
establish which frequently changed files (configuration files, caches)
we should be ignoring, and to set default save directories.
  If a kid writes a file to a very strange place, inotify handlers will
allow the journal to keep track of it.  Existing code (used for similar
indexing applications on Linux desktop systems) could be used to glean
file metadata.  After modified files are located and metadata gleaned,
the Journal would be free to play the same role as it currently does.


To provide a fallback, base-level collaboration system:

 *) Offer a collaboration directory in the user's /home/olpc/, such that
simple filesharing can take place.

  This directory could be managed similarly (reactively to user-driven
events) using inotify and a collaboration daemon which manages the
broadcast and sharing of files.  I'm imagining a network-shared
directory such as those found in systems such as NFS, sshfs, samba, etc.


-------

These are just shiny ideas.  I thought I would posit them publicly for
eventual comment.

Erik