[sugar] 9.1 Proposal: Files

[Benjamin M. Schwartz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mel Chua wrote:
> I'm going to try to reword this as a list of features that would potentially
> be good for the XO to have

Me too.  I should make my bias clear:  I believe we should put our efforts
into improving our existing datastore/Journal implementations, focusing on
pure-userspace solutions with carefully considered semantics, robustness,
and performance properties.  I have yet to be convinced that any
filesystem-like proposal can provide the behaviors that I believe we
require.  If we give up on these behaviors, then there is hardly any
reason left to develop Sugar, and we should instead just ship a standard
lightweight desktop.

> 1) Compatibility with existing applications

Problem: In current Sugar, Linux/X applications that are ported without
source-level changes cannot retrieve and store data to the Journal.

Erik's solution: Throw out the current datastore and API, and replace it
with a straight POSIX filesystem.  Remove the Rainbow layer that prevents
Activities from accessing files to which access has not been granted
explicitly by the user.

Other solutions:
 - Throw out the current API and replace it with an API implementing
similar semantics but routed through the VFS layer instead of DBUS.
 - Write a userspace wrapper that copies files out of the datastore using
the current API to an appropriate location, and then copies the modified
files back into the datastore when the file is updated (e.g. using inotify).
 - Replace the GTK filechooser with a Datastore-aware chooser (e.g.
http://wiki.laptop.org/go/Journal%2C_reloaded)

> 2) Data access and user-perceived reliability:

Problem: Users can't find things because they're not providing enough
metadata for search to work, and there's too much stuff for them to find
it without search.

Erik's solution:  Only keep objects by saving them as files.  This forces
users either to choose a unique name for each item they produce or to
close an Activity instance without producing a file.  Unique names provide
searchable metadata that may improve the effectiveness of search, and
requiring users to type in a unique name in order to save may reduce the
number of objects that are saved, allowing easier non-search navigation.

Other solutions:
 - Use modal dialogs to encourage users to provide better metadata such as
titles.  (We may then easily experiment with making titles optional or
mandatory.)
 - Reduce the number of unwanted objects that accumulate
   - by providing a "draft mode" option that does not produce any object
     - but still produces a listing in a separate Actions view (see
http://wiki.laptop.org/go/Designs/Journal)
   - by resuming previous instances by default, so as to encourage
continued work on existing objects
   - by automatically "starring" only those objects that have been titled
      - and automatically deleting the oldest unstarred objects when
necessary to free space or declutter the Journal
      - and emphasizing or only showing starred objects in the default
view of the Journal

> 3) Resting on upstream stability:

Problem: Our current datastore is buggy.

Erik's solution: Replace the datastore with a standard Linux filesystem
that already has millions of users and is maintained by upstream developers.

Other solutions:
 - Write a dramatically simplified datastore that is less likely to have
serious bugs.
 - Join with Gnome and other projects to produce an upstream datastore
that serves our needs, is maintained independently, and has many stakeholders.
 - Devote more OLPC developer time to the datastore.

> 4) Collaboration

Problem: Users can't send Objects to each other directly over the network.

Erik's solution: store Objects directly in a Linux filesystem, and then
use a standard file-sharing mechanism such as an HTTP server to list these
files, possibly with some access restrictions.

Other solutions:
 - Use Scott's HTTP-based networked object sharing system that runs over
Xapian and the datastore
 - Implement the push-to-share plan drawn up at
http://wiki.laptop.org/go/Specifications/Object_Transfers

> 5) Hackability

Problem:  A sophisticated Journal-like interface abstracts away the
behaviors of the underlying filesystem.  This means that using the
interface does not provide children with knowledge required to understand
and alter its implementation.

Erik's solution:  Provide a direct view into the underlying filesystem as
a first-class component of the interface.  In this way, children will gain
familiarity with POSIX filesystem semantics and so be better prepared to
modify Sugar.

Other solutions:
 - Extend the Journal so that it is easy to write Activities without
touching the filesystem.
 - Accept the two systems as a necessary cost in order to provide a richer
user experience.
 - Regard the filesystem as a low-level implementation detail, as we
regard a raw block device.

> 6) System modularity

Problem: The datastore is a linchpin of the system.  If it fails, the
system stops working.  If its API is changed, then potentially all
Activities and many other system components must be updated to the new API.

Erik's solution:  Make Activities use the standard POSIX filesystem API
instead, placing their files directly into the user's filesystem.  Drop
any datastore functionality that cannot be expressed through this API.

Other solutions:
 - Accept the datastore as one linchpin among many.
 - Improve the datastore design for better robustness
 - Provide an API wrapper using FUSE or inotify so that Activities may
store data into the datastore while being aware only of the POSIX
filesystem API.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkkH8uAACgkQUJT6e6HFtqRmLgCbBAOg0SstRiHbW82YI/n0KSe/
g7YAn0abgz0ter8fcVpuX7KJ8CzHI0DW
=tfFW
-----END PGP SIGNATURE-----