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

[Erik Garrison]

These are suggestions with a longterm focus.

On Thu, Jul 17, 2008 at 01:02:04PM -0400, Erik Garrison wrote:
> 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