9.1 Proposal: Files

[Erik Garrison]

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