Hello all,

After reading Dan's response on this matter, I think we should all
volunteer to do whatever's necessary to free up more of his time for
writing!

In the course of answering some of Peter Smet's concerns, Dan mentioned
the fact that I maintain my "goodies" and applications as separate
file-ins, and I'd like to expand on this a bit.

Every multi-developer software package has to face the issue that Peter
raised: utility vs. bloat.

One solution would be to include all moderately relevant and working
code in the "default" image. This would also leave us with a system
that's simply too big to run (we used to call these "kitchen sink"
images). (I'd say that the current system is already WAY big -- I never
use Baloon, WonderLand, PWS, etc. personally)

At the other extreme, we could opt for a truly minimal run-time system
and relegate all non-essential code (and even development tools) to
file-ins, loadable packages, or somesuch. The down-side of this is that
the default system would not be good for anything (like the libc.a or
clases.zip files)

The only compromise between these extremes involves someone or some
group making the "cut" decision. At present, "sq-central" plays this
role, but anyone in the world is free to create and post their own
change sets or pre-compiled images (as I do for several different
packages I maintain).

If we have extra effort to invest, I'd vote that we try to move Squeak
more in the direction of a small runtime with loadable packages (as has
been discussed ad nauseum already in these pages).

I'm not clear as to what the advantage would be to setting up a second
group outside of Disney to make releases. It reminds me of the
fragmentation in the Linux world these days, with loads of redundant
work leading to wasted effort and missing functionality (e.g., there are
still no drivers for the USB bus in the new PowerBooks, but 3 different
groups are working on it for different flavors of Linux). On the other
hand, a number of us already do make our own releases. If users are
frustrated with the rate of inclusion of new features in the main
release stream, I'm accepting offers for code inclusion in the
STP12/SMS/Siren/Paleo line of images.

It would be nice if there were a current "catalog" of file-ins,
packages, etc. such as the (partially up-to-date) swiki pages for
listing tools, applications, work-in-progress, etc.

Dan ends with a proposal of how things might work in the ideal world;
this is welcome and looks like a good point of departure. My only
warning is that we have tried this in the past and had serious problems.
(For the MIDI primitives, we followed almost the exact steps Dan
outlines and still ended up with several sets of non-compatible
primitives [and none at all that work in the most popular VM]. This kind
of process needs to have well-understood committment from both parties.)

In sumary -- I don't believe that the current model is broken enough to
require major repair, though there are areas we could all work in
improving.

-- 
stp

Stephen Travis Pope | stp at create.ucsb.edu |
http://www.create.ucsb.edu/~stp