Modules
Colin Putney
cputney at wiresong.ca
Sat Feb 26 22:40:48 UTC 2005
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
More information about the Squeak-dev
mailing list
|