[modules] documentation pages on the swiki

Henrik Gedenryd Henrik.Gedenryd at lucs.lu.se
Thu Sep 27 21:37:39 UTC 2001


I have now created a page on the swiki for building documentation about the
modules system. Currently it lists the specification that exists, plus
copies of mail discussions that may be helpful.

http://minnow.cc.gatech.edu/squeak/2042

(Unfortunately writing "modules" instead of 2042 doesn't work since the
swiki gives the first match not the best match. And while I'm complaining,
the swiki has been practically unusably slow, since midnight at least, my
time.)

In particular, there is a page with the proposal for an image architecture
that I mentioned in my reply to Stephane.

http://minnow.cc.gatech.edu/squeak/2057

If people agree with this, it would become the basis for refactoring the
image into a modular Italian dish. Ah, what the, I'll copy in the text here:

A proposed image architecture
General principles for reorganizing the existing image 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.) 

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.






More information about the Squeak-dev mailing list