No subject

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