Decidedly a huge topic.

I want, over the next few days or weeks, to outline a series of 
scenarios regarding various usage situations, or perhaps motivational 
examples to better illustrate where, at least for myself, there is a 
percieved need for this thing we are calling "modularity".  I'll start 
with the first one that got me on the road to Oasis, but that will be in 
another message.  For now, I have some other comments about the overall 
effort.

Regarding the Modularization of the Modularization effort itself:  To me 
it seems that there are three primary efforts that could be going on in 
parrellel.  These are: Source Code Configuration & Management ( eg: 
CVST, and ModSqueak's repository ), Conflict resolution ( Collage's 
Layers ), and finally The Target ( where the classes and methods will 
live ). The Target is what you would normally think of as being 
Smalltalk.  I am using "Target" for now, rather than "Module", for a reason.

The thing to note about this is that the Target really should not be 
particularly aware of how conflicts are being resolved.  It is merely 
the dumping ground for code, the realization of some form of conflict 
resolution over a set of things which have come from a variety of 
sources.  The Target is the end result of compiling the code- in other 
words, the thing hanging onto classes and methods.  Modules and our 
well-known global called Smalltalk are both examples of a Target- and I 
would contend that whether the target is one or the other should have no 
bearing on the operation of the Conflict Resolution layer, and 
absolutely none on the operation of the source code management system.

Likewise... conflict resolution is the place where code definitions are 
living.  But NOT the classes and methods.  It MUST be possible for 
conflicting definitions to co-habitate, and to be resolved through some 
means, either automatic or via user intervention.  This is where I think 
that the Layers in Collage would prove to be very useful devices.  The 
user must have the tools to be made aware of conflicts, the impact each 
has, and the means to resolve such conflicts, without the burden of 
being forced to have the definitions installed as operational classes 
and methods first.

Finally, the source code management system should not concern itself 
with the tasks that exist in the domain of the conflict resolution 
system, or in the spaces containing classes and methods.  It should be 
solely focused on delivering code, specifications of classes, methods, 
and other things, as requested.  This way, if you wanted a totality 
where all that happeneed was that the code got delivered into a 
traditional single-namespace Smalltalk image, it could do that, because 
it has no concept of trying to do anything other than retrieving code 
and providing it to some tool that actually does know where the code is 
going.  Such a tool might also decide that it would like to load lots of 
  code for many variations of a single system into a whole slew of 
Layers down in the conflict resolution space.  So be it- it isn't up to 
the source code management system to be concerned with that.

So, to recap: I see there being three primary areas of effort, which are 
relatively independent of one another.  Differing solutions in each of 
these three areas should be equally interoperable with differing 
solutions in the other areas.  I am not aware of any reason why this 
should not be the case.

Good Luck!

- les