Colin,

Consider the case where there are dependencies between the modules and more than one version of each module.  The current effort of implementing modules is attempting to deal with these issues, and it is a non-trivial problem.  It is also possible that because of certain interdependencies between different versions of different modules that some modules may become mutually incompatible.  This situation is witnessed with MS Windows .DLL libraries quite often.

One common effect is that some applications have to be installed on a Windows machine in a particular order in order for them to all function properly on the same machine.  There can arise instances where because of different sets of .DLL versions required, a set of applications may not all function correctly on one machine.

And regarding SqueakMap and DVS, realize that these are based on the monolithic image model.  They are more or less fancy user interfaces to manage filing in the various change sets (I know I'm oversimplifying a bit, but the point is still valid).

Of course, monolithic systems have the issue of shared namespaces which can make it difficult to make different packages play nice together in the same image, so like I said, the problem is non-trivial.

While it would certainly be possible to produce an MPEG player image, with only the items necessary to play MPEGs, and a MIDI image with only the items needed for MIDI processing, and so on, factoring out the common components can be difficult.  This is especially true when some "applications" use different versions of a particular component and rely on some characteristic behavior.  A hardware example of this is the 4046 phase locked loop IC.  It is a fairly standard part, BUT the Motorola Version and the Philips versions are incompatible in that the external timing components require different values to get the same frequency out of the two parts.  The same kind of thing can happen in software.


							-Dean


-----Original Message-----
From: Colin Putney [mailto:cputney at whistler.com]
Sent: Wednesday, October 30, 2002 8:03 PM
To: squeak-dev at lists.squeakfoundation.org
Subject: Re: An uncomfortable question


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