By reintroducing the concept of files to our systems we can simplify our work in a number of areas relative to 8.2:
- Compatibility with existing applications: One of the principal reasons that the tens of thousands of open source applications that run on Linux aren't usable under Sugar is that we have a custom API for saving data. To make them usable we have to exert developer effort for every ported application. This does not scale and is not sustainable as we are completely alone in this effort. Furthermore, reintroducing files to our APIs will simplify the process of running Sugarized apps in non-Sugar environments, and provide consistency to users who use them both within Sugar and outside. - Data access, user-perceived reliability: Using files forces users to be intentional about saving data (they must name their work). This makes it easier for them to find things they care about--- provided, of course, that they are taught how to save files as students are in virtually all computer-based education. - Resting on upstream stability: Files are used virtually everywhere else in the computing world, and most certainly in our upstream distributions. Using files means we have the same problems as upstream, and no more. If there is a filesystem integrity problem in the Linux kernel filesystem drivers we can more readily expect the aid of upstream users and developers in resolving the issue than we could expect such aid in the case of a custom data storage system. - Collaboration: Many collaboration issues could be resolved by exposing file-based asynchronous collaboration to users. Files are the core component of collaboration in every other computing environment in common use. Using them as a primary storage system will greatly simplify the process of sharing between an XO and a non-XO. - Hackability: >From the beginning of this project there has been a lot of hype about the hackability of the system (Sugar) relative to other computing environments. Python was chosen as a programming language for the environment because of its legibility and ease of use, and we are still supporting it for this reason. However, it is unclear how hacking is supposed to proceed within Sugar without some exposure to the underlying filesystem. Even if it is possible to do via the Terminal, we are not making it easy for users to start by providing two incompatible views on data. - System modularity: Files are a common abstraction which allows the interaction of any applications which can do file I/O. Using user-named files as a base-layer storage system, and not a database or hash-based file naming scheme, allows us to decouple the application which saves data from those that are used to search and index it. I propose that 9.1 include a very simple (perhaps default) way to save files to the user's home directory, and that it also include a file manager skinned or redesigned to work well within Sugar. The most reasonable thing may be to simply save files into the user's home directory if the user explicitly names/saves their work in a given application. Sugarized apps which use the Sugar Activity API can be trained to auto-save files into an auto-save directory of some kind, from which data is eventually deleted if it is never accessed again by the user or tagged/named. Auto-saving seems to be a very important feature for kids--- but so is intentional saving, as it is a common feature on every computing environment in common use and consequently has great educational importance. To provide coherent access to these files we can index them and use the Journal or a compatible index browser for search and data access. I further propose that we use a webserver with a directory listing to enable asynchronous, file-based collaboration between any two XOs on the same network [1]. Doing such would also enable collaboration between XOs and non-XOs. If we want to enable a more interactive collaboration system of this nature we can investigate the use of WebDAV or an equivalent system. I also propose that to enact this solution we relax the security system which is used to sandbox applications running on Sugar. There are certainly ways to keep the security system and enable the use of files, but all of them are by definition more complicated from a development standpoint than relaxing the security system and simply letting applications write to user-owned directories. Erik [1] http://lists.laptop.org/pipermail/devel/2008-October/020660.html _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel