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
