Hi Marcel!

> 
> My suggestion would be to start with something minimal, something  
> that (a) can be implemented without changing existing semantics (b)  
> is a step in the right direction and (c) isn't too difficult.

The system I have is built in VisualWorks, but here are my observations...

> One thing that came to my mind is a very, very simple implementation  
> of a modularization mechanism, the ability to integrate Squeak  
> classes/methods (no more!) into an image without actually copying the  
> stuff into the image (read-only, shared).

Done... although not in the manner you will want ( just yet ).
In my system these imported things are kept inert, but it is also
possible to let these things be active.  To do this requires
module-savvy classes, compilers, parsers, scoping mechanisms,
etc- otherwise one gets "leaks" into the normal image.  But I already
have most of this in VisualWorks- only missing the non-inert versions
of the classes, due to my emphasis on analysis of the inert classes.  

> This could be accomplished by having cover class-objects that refer  
> back to a read-only part not part of the image and also to a normal  
> writable part (possibly empty) that is part of the image.  Any  
> modifications made go to the writable part, which overrides the  
> read-only part.  The pointer to the referenced read-only part would  
> probably have to be hidden from the garbage collector.

Something like this is a good first step towards accomodating active
modules ( as opposed to the inert ones I have ).  Basically, in order
to close the scoping needed to get the module going, I plan to copy
classes out of the "normal" image, treating the normal image as a
big module with lots of exportable resources.  These copies would go
into a special module that could be shared by any number of other
"modules" ( term used loosely- I have several other module-like things
in my system ).  The special module would be a dumping ground for
all the things that have to be brought in to get the other modules to
work while keeping them isolated from the rest of the image.
BTW, due to the massive coupling presently existing, this dumping ground
could easily grow, to a first order approximation, to being roughly 
comparable to the base image- not only do you support the other
modules, you have to support the "special" module, and before
you know it, as you reach for the book the whole shelf comes down
on top of you ( a Berardism ).

However, one might not have to do this copying for every case-
it may be needed only in cases where a class is modified in some way.
As long as it is merely a case of extending a class, no big deal.
Trickier things are what to do when multiple modules define differing
behaviors for an object that travels across their boundaries... Ralph
Johnson has some ideas on this.  But if this is not going on,
there really is no need for any VM modifications.  But to do this
sort of thing, I suspect that very quickly one will have some
desire to modify the VM.

Another issue is the manner in which a module's needs and available
resources are specified- just saying "I need an OrderedCollection"
or "I have a HyperSpaceWidget" is good enough for some cases, but
perhaps not all.  This is where a form of object interface could become
useful, and to do this I've built an analysis system that constructs
a model of the messaging interconnections among classes within the
scope of module-like spaces.

> The system behaves exactly as it does now, changes are made to the  
> local image and override what is in the loaded modules, which are  
> themselves not modified.  Once modifications to a module are well  
> established, a new module with those changes incorporated can be  
> generated.

At this stage I don't have much of a model for editing modules-
they are defined in some manner, and from that point on I try
to handle them.  Doing this in a manner that improves the fluidity
of problem solving within Smalltalk is very important to me, hopefully
someone out there has some good ideas on this.

> The semantics of such a system would be similar to remote messaging  
> to a separate image, but with a fast local messaging implementation  
> and local override capability.

A good proving ground for the later stages...

les