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 at netvision.net.il]
Sent: Saturday, December 21, 2002 4:00 PM
To: squeak-dev at 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