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