Herewith a resumption of this thread from a month ago -- I kept the old subject line just for continuity.  I'm really writing this for my own benefit, but thought various folks might be interested.  Don't bother to respond immediately, as I hope to follow it shortly with a sketch of implementation details.

We now have the ability to export/import projects from Squeak, and to swap them in and out very quickly (less than a second per megabyte) using imageSegments.  Projects are a wonderful unit of exchange because they define an entire world, and yet they can be brought into an existing Squeak as a non-invasive simple icon.

There are two weaknesses with the current state of the project import facility...

1.  Any outside pointer into a project interferes with the imageSegment mechanism.  Thus any global variables in a project (and this includes any classes right now) will not be included in the module that gets written.  This is not a problem for export/import, but it is a problem for module swapping.  This problem would be solved if there were another variable scope associated with projects.

2.  If an incoming project defines global variables, they may interfere with the bindings of the receiving system.  This, too would be solved with project-local variables.

Just for perspective, the real goals of this project will be met if these two problems are solved.  However there are at least two other goals that are so closely related that it would be a shame not to meet them as well...

3.  The simple solution to 1 and 2 does not provide for code in one project or package to refer to variables local to other projects.  It would be nice to have a mechanism to do this.  Moreover, from a package-management point of view, it would be nice if each project declared the names of the other projects from which it expects to import references.  This extends project packages to serve multi-package software projects.

4.  It would be nice to leverage off the existing isolated-project mechanism so that if a project includes changes to the base system classes, then those changes would be reverted upon exit from that project (which should include most unrecoverable error events)


For the system itself, this should be adequate to allow the image to be divided along such lines as Kernel, Sound, MVC, Morphic, Development, Interpreter, Network, etc., not just as a categorization, but as segments that only occupy space when they are actually in use.  Moreover, for access to remote content, we would hope to realize the following scenario...


You open a Squeak Project Browser viewing files on UIUC or Squeak.org.  It shows thumbnail images and a paragraph of descriptive text for each of the projects.  Hopefully these files could also be viewed from an unadorned web browser.

You select a project named ThingLab (for example), and import it.  It takes however long you would expect, possibly enhanced by some simple compression.

When it has all come in, a project icon appears on your screen, just as with projects now, and just as you saw in the remote project browser.  But now you can enter the project.  When you do, you might see a source code browser for the ThingLab code, and also some examples to play with.  The ThingLab code might well include a class named Line, which conflicts with an existing class name in the base system, and it might include a change that allows dots to be embedded in selector names (these are not a contrived examples -- both are the case in the original ThingLab code).

Your system might have grown by 500k due to this import.  If you have enabled the 'projectsSentToDisk' preference then, when you are not actually in the Thinglab project, you see almost no decrease in Squeak's space left.  Also, when not in the project, you see none of the effect of ThingLab's changes to the base system, and there is no effect on accesses to the base class Line.  When you re-enter the project, you see no more than 1/2 second delay to bring in the associated segment.

If you later decide you have no further interest in this project, you can delete it.  At this point your system should not be changed in any detectable way from its state before the import.  The result of 'space left'  should be identical to what it was before, if you have only worked within that project.

As I said at the beginning, I'll sketch a couple of possible implementations, and then it would be good to have some criticism and suggestions.

	- Dan