[sugar] Write needs your help (was Re: Programming environments on the XO)
walter.bender at gmail.com
Thu Jul 17 14:56:36 EDT 2008
It might be a good longer-term focus to see if we could get some of
the Bitfrost ideas pushed upstream rather than diluting them. It has
applicability well beyond OLPC and Sugar.
On Thu, Jul 17, 2008 at 2:33 PM, Erik Garrison <erik at laptop.org> wrote:
> 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.
> Devel mailing list
> Devel at lists.laptop.org
More information about the Devel