Hi Dean,

I'm not sure that I understand your concern. Modularizing the image 
would be a very good thing in my view of the world. In fact, I think 
it's required in order to build the kind of task-specific system you 
prefer.

Modules would let us build custom images for specific purposes, rather 
than attempt to make the standard image flexible enough for any 
purpose. If I'm using Squeak for a web application, I don't need an 
MPEG player in the image. If I'm developing a MIDI application, I don't 
need Comanche.

With the monolithic image, we get bitten coming and going. Not 
*everything* can be in the standard image, so we frequently have to 
file in additional classes to get the functionality we need. With the 
current system this a hassle, much more difficult than it needs to be. 
On the other hand, the standard image has a bunch of stuff that won't 
get used most of the time, and removing it from the image is a more 
than a hassle, it's a nightmare, not to be attempted by mere mortals.

So by all means lets consider our goals carefully. I really like the 
scenario that's emerging from the interaction of SqueakMap and DVS. I 
hope that we can arrive at a very basic kernel in the image, with 
easy-to-install packages available from SqueakMap.

Cheers,

Colin

On Wednesday, October 30, 2002, at 01:46  PM, Swan, Dean wrote:

> What 3.3a is trying to do with modules is essentially opening the same 
> can of worms that has made MS Windows such a maintenance nightmare.  
> Modules are (more or less) equivalent to .DLLs and may end up with all 
> the associated issues.  I don't know of any "good" solutions to these 
> problems, but as attractive as the "idea" of modules is, I am 
> personally content to stick with monolithic images for the forseeable 
> future.
>
> The whole concept of "software components" is IMO a fantasy propagated 
> by media hype that ignores all the realities of real world 
> engineering.  In "real" hardware product designs, one often finds that 
> re-usability is more of a structuring concept than a hard reality.  I 
> don't believe I've ever worked on a hardware design that didn't 
> involve some kind of custom connector that is a "slight" variation of 
> a "standard" connector, for example.  (Just for context, I'm referring 
> to everything I've worked on in the last 12 years or so).
>
> I think the concept of a monolithic image constrains the reusability 
> myth to realistic proportions, and makes implementation possible.  Too 
> much flexibility comes at a cost, which usually rears its ugly head in 
> the form of increased complexity, higher resource requirements, and 
> reduced preformance (relative to a less flexible implementation).
>
> As an example of what I'm talking about, I've worked on a couple of 
> different projects in the last few years where the end product has 
> similar capabilities but one was implemented using a "flexible, 
> reusable platform approach" and the other was implemented using a more 
> task specific approach.
>
> The flexible system has a source tree for the "platform" of about 5 
> gigabytes, generates a target image of about 170 megabytes, and needs 
> two 300 MHz PowerPC 603e's and 512M of RAM to run.  This system has 
> hundreds of developers working on it.
>
> The "task specific" system has a source tree of about 300 megabytes, 
> generates a target image of about 1 megabyte, and runs on one 66 MHz 
> PowerPC with 16M of RAM.  This system had 4 developers working on it.  
> The end functionalities of these two systems is *very* similar.
>
> I'm not sure what my point is in all of this, but I think we should 
> consider our goals carefully in relation to the questions that Andrew 
> has raised.  My preference is towards "lean and mean" rather than 
> "incredibly flexible, general purpose (and suboptimal)".



Colin Putney
Whistler.com