-----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----- _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar