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

[Tomeu Vizoso]

On Thu, Jul 17, 2008 at 7:02 PM, Erik Garrison <erik at laptop.org> 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.

Sorry, I wasn't clear above. I wasn't meaning that running unsugarized
apps wasn't a desirable thing, just that I believe that activities
like Write and Browse bring important value to our mission and would
be a pity if these efforts get lost.

> 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.

The one I mentioned above, that we can offer a better experience to
our users than the one currently offered by existing desktops and
apps.

> 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).

You mean abandoning any of the security goals?

>  *) 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.

I would love to move to such an scheme, these are the unsolved (for me) issues:

- versioning (solved if we use olpcfs?)

- consistency inside entries: most probably we'll need several files
to represent a single journal entry. The journal thus would need to
know when an entry has been fully written so it can be properly
presented in the UI.

Not too much ;)

> 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.

Well, once we can share any entry or object from the journal, would we
need something like that?

Thanks for bringing this issues again, we surely need to keep banging on them.

Regards,

Tomeu