[sugar] Develop Activity

[Ian Bicking]

Dan Williams wrote:
> One thing we had discussed with respect to an IDE was that it should
> hide all directory structure in the GUI.  The child could create
> categories or something, but there's really no reason whatsoever to
> expose that when the only thing that needs it is the activity.info file
> and the icon, both of which are in the same directory.
> 
> We don't have a "file manager", so there's no other place where
> directories are/should be exposed right now.  "objects" added to the
> project (be they icons, python code, pictures, whatever) could be tagged
> with arbitrary tags and sorted by those tags in the project layout.
> Python makes things somewhat complicated by imposing a directory
> structure underneath the 'imports' command, but for the moment we had
> thought that a simplified activity IDE for children should just show a
> flat structure.

Ah, directories, filenames, and compound documents -- the big open 
issues in the document store / journal.

An activity in this sense is something like a compound document.  It's a 
single entity with many pieces.  These pieces are all related to each 
other.  The way these relations are traditionally represented is through 
filenames.  (Many of the same issues apply to a compound HTML document, 
which refers to things like images by filename as well)

Well, if it's more palatable to the people who dislike files, "filename" 
isn't *strictly* what is required here.  It could also be called a 
"resource name".  And indeed, we can hack around Python's imports fairly 
easily to have it load things from the document store instead of reading 
concrete directories and files (though this may or may not end up being 
useful).  But we *can't* remove the idea of named resources.  You can do 
that in Squeak because it's been built that way, but it's way too far 
from any of the other programming environments to be reasonable.

This doesn't mean we need a global directory structure.  I think it does 
mean we need two things:

* The idea of a bunch of resources collected together.  In the case of 
an activity, that means some source code, some images, the .info file, 
and whatever else.  We've already given this a name: an Activity Bundle. 
  It's important for more than just Activities, but we don't have a name 
or clear idea for what that larger concept is.

* The idea that, inside that bundle scope, things have names.  These 
names might be "activity.info", or "mypackage/mymodule.py". 
Traditionally / indicates hierarchy; but you can also just view them all 
as string identifiers.  The string identifiers are important, of course 
-- mypackage/mymodule.py maps to mypackage.mymodule in Python.  We can't 
choose these identifiers randomly, these need to be explicit and 
persistent identifiers created by the author.

In some cases we *can* create names.  For instance, if you have an HTML 
page and an image (or a Crossmark document and an image), the name of 
the image isn't that important.  But once it gets a name, the other 
document will also get a reference to the name (e.g., in <image 
filename>).  So the name has to be persistent, even as the resources are 
moved around.  It can't be a hash, for instance, nor something that is 
volatile when the bundle is moved around (as some resource-UUID 
proposals use the UUID).  In that case the name is a kind of reference, 
and we need to keep the integrity of that reference and the relation 
between the resources, but the name of the reference is incidental. 
It's just that not all names are incidental.


-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org