links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
A proposed modular image architecture
Last updated at 2:36 pm UTC on 16 January 2006
General principles for how the .image file and the Squeak system should be divided into separable Modules.

Goals for the module structure

There is so much reorg. needed for "doing it right" that we need to decide on a few reasonable goals that are our most immediate needs and focus on how to solve those first.

I propose these:

With these goals in mind, I have started to analyze the code, and I wrote some tentative reorganization code. I realized that we need to decide on a modular architecture for reorganizing the system. That is, a few overall principles for how the modular system should be organized. Then people could adopt these, take on the image part of their choice, and start working on refactorings and submitting the code.

An "onion skins" module architecture

Wrt such principles, I saw a repeating pattern. Most "major" category functionality (Morphic, Network...) can be divided into these "minor" categories: Essential, Useful, Applications, Tests, and Demo/documentation/examples. This pattern works for Morphic, 3D, Network, FFI, Archives, Exceptions, Kernel/System, and more. It is like the "onion layered" OS architecture, where further in is more essential, and modules may use other modules in layers further in, but not further out. It also provides useful segments for building different images for various purposes.

Renamed/new major categories

Note that we'll need to rename "Kernel", it is so similar to Core to be confusing. Also "System" is a very weird major category–what system? Squeak? The OS? etc. My idea was to instead have Language and Technology (vs. "Media"–3D, speech, sound, etc.), where these needn't correspond directly to Kernel and System.

Moreover, "Tools" is highly ambiguous too. Perhaps put these under a new "Development" header, to hold everything that could be purged from a finished application: browsers, debugging tools, compiler, etc. (hg)