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 <[EMAIL PROTECTED]> 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@lists.laptop.org > http://lists.laptop.org/listinfo/devel > _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel