A little note about how we're going about it - In the spirit of modularizing the modularity effort, I'm not sure there's a need to centrally cut everything up.
I propose this way of doing things - * Get the Modules code in the image, * connect things to a repository, * publish a small step by step recipe to carving out a proper module.
and then see my recent Updates mail.
Given code and something clear to do with it, I think people will take care of the rest quite naturally. I think it's better if he who will maintain a module marks his own "territory".
Just a thought.
Daniel
Henrik Gedenryd Henrik.Gedenryd@lucs.lu.se wrote:
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 can1t 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/2finished2 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.
squeak-dev@lists.squeakfoundation.org