[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
|