>MODULES
>[...]
>While I worked hard to make this possible, I don't know how important it is.

I not only consider this as important but as essential.  A working module
system is essential for a bazar-style exchange of Squeak code compared to
the cathedreal-style approach of the master image.

A large monolithic image has IMHO another drawback which wasn't mentioned
yet. Because it's so comfortable, people don't thing about what
dependencies the subscribe to when adding code and you'll get a mess of
inter-dependend code which can't really separated.  This adds a lot of
unneeded difficulty to stripping.

IMHO, simply following the 80-20 rule and removing 80% of the code
(probably the classes of certain categories) isn't good enough.  I want to
get rid of all 100% of code, especially of all this extensions to classes
like Object.

>Moreover, breaking the image up into a lot of little modules actually makes
>it harder to release and harder for a newbie to download and understand.

I think, it's quite the opposite.  Downloading would be simple if their's
either a nice web page explaining each module or if you simple download one
big ZIP file (direct URL-download is of cause also an option, but please
only an option).  I don't mind to download a big chunk of code, but I don't
want to read through large chunks of sparely (if at all) documented code.

Reducing the classes and methods means reducing the complexity means
lowering the border means easing the understanding.

Releasing is also not more difficult (also not easier, I agree) because you
have to carefully keep dependencies in mind.  However, because now
different modules can have different owners and maintainers, the work is
distributed much better.

>However, it's not yet clear to me that this is how we want to release 
>the system.

Please consider this.  Eventually, I'd like to see a system like SELF,
which could bootstrap itself from literally nothing.  Okay, the inital
class and object framework of Smalltalk is more difficult and complex than
that of SELF, but I could imaging a fairly small core image which could
nothing more than readin more modules.  Then, the first modules should
contain the very basic classes like Boolean, Number, etc.  I'd imagine
something like <100k.  Now you could choose whether you want to headless or
a GUI image by either loading some basic console I/O stuff or a core
graphics framework.  Based on that graphics stuff, Morphic and/or other GUI
frameworks could be loaded, eventually loading development tool (which are
of course!) separately available.  You could even think about replacing the
standard SmalltalkCompiler with a different compiler which can simply
generate the same bytecode set but features a different language.  I'd also
separate most meta-programming aspects from the rest of the system, as
these features are most often used for development but seldom for deployed
applications.


bye
--
Stefan Matthias Aust  //  Bevor wir fallen, fallen wir lieber auf.