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

[Walter Bender]

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.

-walter

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.
>>
>> Erik
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>