Journal, Clipboard and activity instances vs. files (was Re: Recent Updates to Sugar Almanac)

[Wade Brainerd]

2008/6/16 Faisal Anwar <fanwar at mediamods.com>:
> Rather than keeping track of what
> state you are in, it seems more coherent and natural that the developer only
> worries about specific calls to write metadata when he wants to write
> metadata (like volume and playback settings) and only worries about
> file-specific calls when he wants to manipulate files.

Hey,

I've had this read_file and write_file confusion before too.

I think it's an issue in the design of Sugar, where there has been an
attempt to mix "files" and "activity instances".  This leads to
problems like when you plug external storage into the XO and all these
fake "activity instances" appear in the Journal and have to be
filtered into the datastore, even though they are really just files,
and the usability issues with the Journal spending time indexing,
removing file extensions, flattening path hierarchy, etc.  Or the need
to pop up the Journal Object chooser when we have a perfectly function
clipboard on the frame.

(If I were designing Sugar from scratch) I would consider linking the
concepts of "file" with "object on the clipboard".  That is, you
cannot start an activity from a file, you can only paste a file into a
running activity instance from the clipboard (or choose the Open With
item on the clipboard context menu).  This takes care of the "Start
with" issue quite nicely.  And Read would not be a special case
activity, you could either launch it and Paste, or launch it from the
Clipboard context menu.  The clipboard would become an arbitrary
"storage pool of mime objects".  It would persist across reboots, and
would provide the user interface to access external storage.  In fact,
it would really just be a simplified UI to a folder tree in
/home/olpc/ (and /media/).

This would leave the Journal as the collection of activity instances
only, while the clipboard would be the collection of plain mime
objects only.  When you download an item in Browse, rather than going
to the Journal, it would go to the clipboard.  Downloaded files could
be easily located in Terminal by checking /home/olpc/.sugar/clipboard/
or similar.  The issue with starting activities in Develop could be
reduced to the context menu of an activity having a Copy Bundle option
which would copy the .xo file to the clipboard, to be pasted into a
new Develop instance.

The effect of all this on the API would be that activities would not
have files to read and write at all, they would deal solely with
metadata, which should clear up the confusion.  The current APIs would
be left for backwards compatibility, but whatever was written would be
packaged up with the metadata and stored in the activity instance.

Hope all this blue sky brainstorming isn't annoying anyone too much :)

Best regards,
Wade