At 11:24 AM 8/18/2001 -0700, Dan Ingalls wrote:

>--
>
>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.

I'd suggest targeting a much smaller kernel with some of the other 
functions mentioned above showing up it additional layers.  For these 
lowest layer I wouldn't necessarily recommend thinking in terms of 
component composition.  Instead I would think of modules that can be 
statically composed to produce the kernels of Squeak images that are 
optimized for differing environments and uses.  Examples of such customized 
Squeaks might be:
         Classic Squeak --  Fully reflective exploratory programming 
environment
         Advanced Application Squeak -- Morphic based, reflective 
application programs without development tools
         Appliction Squeak -- Morphic or MVC applications, non 
reflective,no development tools
         Basic Application Squeak -- Non-GUI applications (full file and 
network support), non reflective,no development tools
         Micro Squeak -- Basic collections, numerics, and external system 
calls  (basic embedded uses)
         Kernal Squeak  -- Supports fundamental Smalltalk language 
execution semantics

In designing the core modules most of the above possible Squeak variants 
should be kept in mind.  A critical test of the modularity system is 
whether it is flexible to allow definition of modules that are composable 
to achieve this range of variations.

The true minimum would consists only of the classes and methods that are 
essential for representing compiled Smalltalk code and executing it on the 
virtual machine.  This includes Undefined Object, CompiledMethds, contexts, 
class objects, probably Symbol and Process, and a few other things. Most of 
the common methods of these classes don't need to be present as the 
operation of the virtual machine doesn't depend upon them. As a point of 
reference, when we did this at ParcPlace-Digitalk we were able to emit a 
minimal image that computed 3+4 and whose total size was about 10K bytes. 
Note that at this level, Object (or is it ProtoObject these days) isn't 
even essential.

The next layer would probably added the essential classes and methods used 
by all application programs.  This is probably pretty close to what ANSI 
Smalltalk specifies as Fundamental Protocols.  Other ANSI Protocols could 
be organized into optional, but typically present modules.

An optional layer would added sufficient introspective reflection to 
support debugging and inspection.

Another optional layer would added the reflection protocols needed to 
support dynamic addition of classes and methods. Note that images without 
this layer must be statically generated by some sort of image writer 
(something like a SystemTracer).  From what I've heard about the ModSqueak 
work it sounds like it is close to provided the necessary infra structure 
to do this.

Dynamic binding of "image segments" should be supported either via the 
above layer or perhaps by an additional layer.

I would make the compiler a component.  It really doesn't belong at this 
level of the system at all.


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

fine


>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.

Fine, does networking go here?

I would list the MVC and Morphic Kernels next, rather than the develop 
kernel.  Development tools are an application so they should be at a higher 
level.

>4. Development system kernel
>All the browser models

ModSqueak's "semantic model" would probably go here too.


>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.

I have a message pending (I just need to type it) on why ChangeSets may not 
be the answer.

We also not need to assume that a complex system is dynamically constructed 
by binding additional modules (I would call such things components) to a 
running image. That is one way to do it, but an equally valid way is 
statically generate the complex image from.  I think to cover the full 
range of uses you have to consider both approaches.

If some of the above seems to be slightly out of left field I suggest 
taking fresh look at:

http://www.smalltalksystems.com/publications/_awss97/INDEX.HTM
http://www.smalltalksystems.com/publications/_awss97/SSDCL1.HTM

Allen


>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