Hi Gang,

Attached is a little sketch that is similar to one that I sent to Dan 
Ingalls about
a year ago. It is a very high-level view of Squeak. The inverted 
triangle
represents the current Squeak image. As change sets, projects, or 
packages
are absorbed by the image, it becomes larger (and larger and larger).
Conversely, as code is removed from the image, it becomes smaller.

Currently, what is inside the triangle is a mass of highly integrated 
spaghetti
code. Attempting to modularize that mass of code is an exercise in utter
futility. But, there is hope.

The current SqueakMap/DVS effort (Daniel Vainsencher,Goran Hultgren, Avi
Bryant, and friends) provides a mechanism for what Dan calls "peeling 
the
image". Once the image is peeled to some level, we would essentially 
have
the Squeak Base Platform (SBP) that I mentioned in my last message. I'm
assuming that the SBP would exist somewhere between Squeak 2.8 (or
Stable Squeak) and Squeak 3.2-4956 plus VI4 plus SM/DVS.

At this point, Squeak could live happily ever after and not make a dent 
in
the module problem. However, once the SBP is defined, it becomes 
possible
to create a new Squeak architecture with defined interfaces that would 
become a
module backplane (aka, a component framework) for supporting modularity.
This new architecture would necessarily provide the same functionality 
as
provided by the peeled image or SBP.

Since SqC (Alan Kay, Dan Ingalls, Scott Wallace, John Maloney, et al) 
have had
plenty of experience in building Smalltalk systems, SqC should probably 
be the
ones to create this new architecture and the primary interfaces. In 
this regard,
they would act as a typical A&E firm.

Once we have a well-designed architecture and a good set of defined 
interfaces,
the Squeak community could then supply the necessary manpower for 
building
the code, acting like a general contractor to an A&E firm.

Since Grady Booch, Ivar Jaconson, and Jim Rumbaugh have more experience
with complex software architectures and systems engineering in general 
than
most folks I know, I would strongly recommend the use of the UML 
(Unified
Modeling Language), and associated tools, for laying out this new 
architecture
both for reasons of documentation and for providing a means for 
understanding
the new architecture in depth by the Squeak community.

Make no mistake about it, I'm talking man-years of effort here, not 
man-days by a
few individuals. There are a number of possible variations to this 
general approach,
but this approach, or something similar to it, should eventually do the 
job.

Comments?

Cheers, Roger.....

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Architecture 1 (DR).pdf
Type: application/pdf
Size: 20221 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20021103/08dd0ea9/Architecture1DR.pdf