[ModSqueak] Re: Toward a Package Architecture for Squeak

Dan Ingalls Dan at SqueakLand.org
Wed Aug 15 18:28:33 UTC 2001


-- 
Folks -

A while ago I tried to start a thread on the above topic.  Nothing happened at first, so I commandeered a few folks with personal messages, and there has now been a significant amount of useful discussion on this topic.

We figure there are probably a number of others with useful experience or who would be interested in contributing one way or another, so we've decided to move the discussion back out to this list with a [ModSqueak] tag.

We will hopefully fairly soon have the messages so far available as a browsable archive.  [If all else fails, I can just forward a dozen messages to this list].

I will try to summarize the discussion so far:

First of all, as I put in my original message, we have a few desiderata that seem to meet with general favor:

	A minimal kernel for the support of modules and
		inter-module dependence within the image

	The ability for weekend hackers to write simple
		programs as easily as now

	A Squeak release that is well partitioned so that
		it can be easily built up from a small kernel
		and fairly easily reduced again to a small kernel
		[thanks to John S and the StableSqueak folks
		for their bold step in this direction]

	We want this soon
		I'm thinking something to test this month
		and a modular Squeak release in September
		(easy for me to say ;-)

At this point we have discussed a number of possible approaches

	The work I did on Environments
	I am hereby withdrawing this from the list of
	contenders because it is a novel design, and 
	incomplete in important areas (eg dependence).
	It may be clever in way, but I think
	that would only hamper one of our goals which
	is reasonable inter-operability with other
	Smalltalk systems.

	Les Tyrell's work on Oasis
	Oasis is really broad in scope.  It addresses
	the problem of how to work on different dialects
	in the same image.  Les has not had a chance to say
	whether there's a kernel in OASIS that would be 
	appropriate for our modest needs, the more
	ambitious parts then being an optional package.

	Joseph Pelrine's work on ModularSqueak
	(Paul McDonough has worked with Joseph on this)
	This appears to be the most complete effort,
	and it's close to the goals of this community.
	A few of us are looking at the latest version
	to get a sense of how it looks and feels.

	Hans-Martin Mosner has also made a number
	of points worthy of consideration, whatever
	implementation we choose.

	Lex Spoon has made a cogent proposal by applying
	the KISS (keep it simple, stupid) principle:
	simply fix what's bad about ChangeSets, and add
	what's needed for recording dependence. 

Not a great deal has been said yet about the process for bringing this plan to fruition.  I have declared a commitment on the part of SqC to incorporate whatever mechanism gets chosen in the next Squeak release.  Various folks have obviously put in a fair amount of work already, or have valuable experience, and it sounds like a dozen or so of us would be enthusiastic testers and fixers as soon as we agree on the approach and there's an artifact available.

I'm generally trying to push this along because I see great value in the product.  Decent modularity will benefit not only Squeak itself, but our whole open source community process.  Also, since SqC is NOT providing the goods in this case, it is a good example of what could be a general approach to Squeak community  projects.  If it all works out, we'll have a pattern for one facet of operation of the Squeak Foundation.

Lastly, there has been some informal talk about possibly using the Camp Smalltalk in Essen as a time for a few people to come together and push the ModSqueak project along (assuming it is in a pushable state by then ;-).

	- Dan




More information about the Squeak-dev mailing list