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