Daniel, very interesting -- the current singleton image would become a Project Explorer image communicating with a cloud of Project images, if I understand you correctly.
I like this mechanism; it seems like it would be simple, easy-to-understand, robust, re-use alot of proven technology, etc. Also it seems like SqueakMap would dovetail nicely with this approach.
Some thoughts:
** Loading Projects **
I'm excited about this because I think that idea of Projects in Squeak is very cool but the experience of unsuccessful-Project-loads is not so cool. As I imagine it, Project windows would be built in the Project Explorer image as follows:
(1) Get the URL for the Project image spec (2) Get the URL for the living objects that will be copied into the new Project image (3) Get the URL for the to-be-created Project image (4) Retrieve the Project image spec from URL in(1) (5) Build the Project image to spec, accessible from URL in(3) (6) Import the living objects from URL in (2) into the Project image (7) Create a ProjectWorldMorph in the Project Explorer image
Steps (1) through (5) would be cool because the work of building a Project is separated out into nice clear simple steps. Dependencies and in general Project metadata become much more accessible. Also we could easily build Project-subscription tools with this mechanism.
I'm still thinking about step (6). Would the cloud of Project images always be headless?
** Programming In Layers **
What are the use cases for programming in switchable layers? I'm trying to think of use cases that this mechanism doesn't address well.
** Unfixably Stuck Images **
A Project Explorer image should be very stable, if it is smart about how it handles its connections to stuck images. One of various Project images in the cloud may freeze, but the rest should be fine.
** Hogging Memory With Big Fat Images **
Headless images built to spec should get Smaller All The Time. Also, I guess the cloud of Project images wouldn't necessarily have to live on the same physical resource; they could live all over the network/Internet, if they communicate in an Internet-friendly way ( and if network/Internet latency ain't a big deal ).
-----Original Message----- From: Daniel Vainsencher [mailto:danielv@netvision.net.il] Sent: Saturday, December 21, 2002 4:00 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: Subjective Squeak
[snip] ...switchable environments - now that's a Model issue.
One PIE paper shows a good role for layers as a model of programming (layers as a programmers product - a unit of code modifications).
[snip] ...I am very sorry we still don't have a model as developed as they did for programming.
[snip]
What our models are is the big question, and how do we start modifying the way we work, to realize them as quickly as possible.
Mechanism vs Mechanism
The more you talk about switchable layers, the more, I think why not get the same capabilities from richly communicating separate images, reusing the OS/separate VM's protection?
About projects - the problem with projects precisely exemplifies the issues at stake. First, you need to have projects be dependent on a specific configuration, and be able to download that automatically (using SM). We're mostly agreed there. Second, you need to be able to activate it, while isolating it properly from your current image. So yes, right now, I know I'd load more projects if they were simply run in a separate, new process.
In fact, when I start to think about it, a complete alternate Squeak universe unfolds. Imagine a GUI image, that has all the GUI tools you want, but doesn't generally run the models. The models run on one or more headless images. I have a mail image, and I have a completely separate development image, but their GUIs run on the same image. Most of the browsers and workspaces simply happen to be connected to the development machine. Communications between the image are kept mostly asynchronous, and on simple, standard protocols, and completely for free, you get a Squeak that runs very well on SMP machines. Or distributed across a network.
And yet at any time, you can connect a browser and an object explorer to a specific image, and KNOW, that in front of you within this address space, is something as simple as a completely self consistent Smalltalk, separate from the rest of the world, except for the above communications.
Daniel
squeak-dev@lists.squeakfoundation.org