Hi Dean,

Let me drop in a note here. Modules are no DLLs - they are not shared
runtime components. E.g., DLL-hell as we know it from Windows is due to
the fact that no developer can foresee what DLLs any customer may have
installed on his or her system at *runtime*. This is very different from
detecting and handling problems at *development* time.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Swan, Dean
> Sent: Thursday, October 31, 2002 2:33 AM
> To: 'squeak-dev at lists.squeakfoundation.org'
> Subject: RE: An uncomfortable question
> 
> 
> 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
> 
>