On Feb 25, 2005, at 7:20 PM, Lex Spoon wrote:

> The module system should ideally be built with some thought of how the
> external packages will be maintained.  We surely want to have stable
> packages around, but there is no such thing as a "stable package"
> sitting by itself.  A package can only be stable with respect to a set
> of other packages that it might be loaded along with.  Thus, we will
> want to have repositories, and repositories will work best if the
> package format has predicted their needs.
>
> One particular issue to think about is how dependencies work.

I'm replying to Lex here, but only because he touches on an issue that 
I've seen come up in many messages on this thread. The above post, and 
Lex's ensuing discussion of dependencies is important, I think, but not 
part of the core issue of modularization of the image. The same can be 
said of my own area of particular interest - versioning. As I see it, 
there are three topics here, which are all related, but largely 
separate and should be addressed by separate mechanisms:

1. Modules. This is about the organization of executable code in the 
image into modules, loading and unloading modules, isolating modules 
from each other, allowing them to communicate, and reflecting upon 
modifying modules, their organization and their structure. This is 
where the E/Islands/Namespaces/security stuff its in as well. We've 
been using PackageInfo as a very, very simple stand-in for a real 
modules system.

2. Versioning. However we decided to slice up the image, we need to be 
able to keep track of how the different modules change over time, 
produce and reconcile different versions of modules, and share them 
between developers distributed over time and space. In the early days 
we used ChangeSets and the update stream for this, but since the 
introduction of PackageInfo for modularization, we've been able to use 
Monticello for versioning.

3. Organization and Distribution. Given ways of organizing modules 
within an image, and versions of modules over time, we still need a way 
to organize them socially. We need a catalog of the available modules, 
what other modules they depend on, who maintains them, where to obtain 
them. We need technical supports to the Squeak community and the 
marketplace of modules. In the early days this was squeak-dev and the 
Swiki, but lately it's grown to include SqueakMap, SqueakPeople, 
SqueakSource and PackageUniverses, BFAV and the Mantis bug database.

I think Dan's modules team should focus on #1. PackageInfo is pretty 
primitive, and we really need something much better. At the same time, 
we're doing ok on items 2 and 3. So while we should definitely be aware 
of and discuss versioning and distribution issues, I'm happy that the 
opening statement Dan made for the modules team made no mention of 
either versioning or distribution. Those are jobs for Monticello and 
SqueakMap, or their successors.

Colin