[modules] Cutting the knot

Dan Ingalls Dan at SqueakLand.org
Tue Sep 25 22:53:08 UTC 2001


-- 
Folks -

I feel the need to cut what has become a Gordian knot.

By the end of this week I intend to issue Henrik's module code as updates to Squeak 3.1alpha.  While this may look selfish or irrational, I think it's the right thing to do, and at this point someone will likely be unhappy no matter what we do.

Our top priorities for modules in Squeak are:

	Support modularity of active Squeak content
	distributed as projects on the Internet

	Support an ecology of interrelated enhancements
	to Squeak from throughout the community

	Keep it small and simple.

This is a Squeak Central perspective.  Others surely have other priorities.  We feel that as soon as we achieve the first goal, Squeak will disappear.  In other words, the significance of Squeak as a vehicle for easily-authored multimedia content will dwarf that of Squeak as a development environment, and all the activity of this mailing list will likely pale by comparison to work on active content.

The ModSqueak work is an excellent system with a somewhat different set of priorities.  It could be made to serve these ends, but I foresee constant conflict in trying to do so.  I prefer to proceed directly toward these goals with Henrik's code, and to allow the ModSqueak facilities to remain one of the packages that can be easily loaded by anyone who wants its particular benefits.

In adopting this approach we will take care that nothing in the resident module scheme interferes with loading and using ModSqueak as now.  Presumably a great deal could actually be shared, once the dust settles a bit, and loading should, of course, become simpler.  What is important is that ModSqueak can remain just what its authors intended it to be, and the the resident module system can be tweaked into a lean and effective architecture for community sharing and active media on the web.

Those who have followed the full modules discussion will recognize that our first priority here is really more of a component architecture, and this is true.  At the same time, we feel that the module kernel will serve well the needs of the Squeak community for collaboration and distribution of add-on packages, as well as producing reduced images for PDAs, servers and other applications.

Yours on behalf of SqC (and wearing asbestos today ;-)

	- Dan




More information about the Squeak-dev mailing list