[sugar] Write needs your help (was Re: Programming environments on the XO)
erik at laptop.org
Thu Jul 17 14:33:17 EDT 2008
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.
More information about the Devel