-- 
Folks -

I'm afraid there is much more about all of this that I don't know than that I do know.  That said, perhaps it can be an advantage...

I know there are several things we are talking about here, and we need to separate them to come up with clear solutions.  What I'd like to do is to propose an operational approach which may help to guide us to getting the "best of both worlds" -- in this case a simple small kernel, but that can support a great group programming engine for large software projects.


[If you're in a hurry, skip to *****
Here's what I mean by an operational approach -- think of how we might release the Squeak system:

1. A minimal kernel
This would be something like the 240k "tiny" image I made from Squeak a few years ago (had compiler, files, minimal graphics (only enough to put up a transcript), collections, strings and numbers).  I would like to go farther with this by using the OS for the transcript, so that all this thing can really do is read in the next package.

2. Basic Graphics
This would be the kernel graphics (Form, Color, etc) common to MVC and Morphic.

3. Full Files
The kernel might only know about the current directory.  This would fill out the rest, along with all the stuff there now that isn't essential.

4. Development system kernel
All the browser models

5a. MVC kernel
Enough to support MVC applications

5b. Morphic kernel
Enough to support simple Morphic applications

6a. MVC development system

6b. Morphic development system

You can take it the rest of the way, through network support, network applications, 3D support, 3D applications, scripting system, etc.  The important thing, that I doubt any of us disagree with, is that the image is built up in a modular way, so that you could do a headless server or a small squeak for PDAs with no space wasted for the other modules you are not using.  Ideally, you could end up with the exact same system whether you built it up from the kernel, or pared it down from a jumbo system -- the modules should be loadable or unloadable in a completely, well, modular manner.
*****]


What does this say about our architecture for modules?  To me it says that what we want to start with in the image is really just the support necessary to receive a new module.  This looks like a fairly small requirement -- it could be satisfied by a combination of Lex's ChangeSet proposal and the existing Environments work, with some cleanups and simplifications.  I'm curious if people generally agree about this and, if so, if it would be worth summarizing this requirement as a sub-project of the overall effort.

A parallel sub-project would be to extend our tools to work with this new architecture.

This would seem to be the first step to shoot for, because it would enable...

	1.  A refactoring of the entire system
	    along the lines above

	2.  More reliable and consistent sharing 
	    of major projects in the community

	3.  A target image specification for the
	    more serious team development tools
	    which could themselves be added as modules.

Do people think this is a reasonable first step?

Does anyone want to propose a spec for what needs to be done?

	- Dan