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:
- An ability to have the equivalent of a majorShrink image.
- Also a PDA image with just a basic Morphic; this mostly involves separating eToy from Morphic–Balloon, 3D, etc. are easier.
- More, a completely headless image (very small, neither MVC nor Morphic). This is a secondary goal.
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.
- Core - Essential parts that can’t be removed or split, like the core of Morphic.
- Library - reusable utility parts that are much like Core but optional/removable, such as various, generally useful morph classes
- Applications - larger, more standalone/”finished” pieces. examples: Morphic PDA, B3D Alice/Wonderlands. Network: Scamper, Celeste, etc.
- Tests - This is for SUnits
- Demo - Demo and example code. nNote that example code often contains a lot of the degenerate cross-modular references. (This is also true for tests and applications.)
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)