[sugar] [PATCH] Journal able to use "open with" for activity bundles

[Benjamin M. Schwartz]

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

I have a proposal for how to manage objects in the datastore, to resolve
the various issues we have discussed.  I call it the "Objects and
Translators" model.  The fundamental idea is this: the datastore is a
flat, non-hierarchical listing of objects (versioned, but that does not
come into play here).  The datastore provides these objects for use by
Activities.  However, the datastore (or perhaps the Journal) also contains
a new element: Translators.

A Translator is a non-interactive object processing machine that takes an
object as input and returns a set of objects as output.  Each Translator
has a specified set of input types on which it can act.  The user, having
selected a particular object, should be provided with a list of all
compatible Translators.  Clicking on a Translator should show the list of
output objects that Translator would generate for this input object, and
the user may repeat this process on each of those objects as well.

This model allows us to reproduce the usual sorts of directory
hierarchies, simply by using a group object (I think of it as a .tar file)
and an untar Translator.  To the user, this looks very much like a
directory hierarchy.  However, because each "directory" is in fact a
first-class object, it can also be associated with Activity instances, or
passed from one XO to another over the network, etc.

The Translator system is appealing to me because it can provide far more
than a simple storage hierarchy.  For example, I have often had to extract
a particular image from a PDF file, in order to include it in a class
project.  I, and most people, have done this by blowing up the image and
performing "Print Screen", or perhaps opening the PDF in the GIMP, which
rasterizes it.  However, there is a much better solution, provided by
xpdf's command-line utils, which allows one to split a PDF into its
component images and text, losslessly.

Almost nobody uses these tools, because they are command-line only, and
obscure.  It would be trivial to wrap them up into a Translator, though,
and then every PDF, in addition to showing options for viewing in Read,
would show an option for splitting into it components, for further
editing.  Nothing could be more in keeping with our goal of creating an
editable world.

You can easily think of many other interesting Translators.  For example,
one could also provide a PDF->PNG rasterizer, a ODT->PDF renderer, or a
Theora->JPG frames decompressor.  The APIs should be designed so that
Translators can be lazy, computing the contents of output objects only
when necessary.

Translators provide tremendously powerful object management, with a simple
path to implementation.

- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhP8SkACgkQUJT6e6HFtqRQrACfcd5ntZ1ZXovZtTVI5k4LEG96
oDwAnjswhuiV1uKJ5cWhVV9N6uFNgT6E
=x7ie
-----END PGP SIGNATURE-----