[Squeakfoundation]core addon packages
Mon, 9 Dec 2002 09:44:53 -0500
I like your focus on building a minimal bootstrap image and describing how
to build onto it. Also the exercise of defining core service frameworks
that can go on top of the base. We should be able to agree on a single
events framework, XML parser framework, base networking framework, etcetera.
I don't believe this will stiffle innovation, but it will allow us to
explicitly define and document (and publish!) core packages.
So what would we define as core addon packages?
Regarding online images: are you suggesting that the squeak map directory
point to live images for the latest packages?!? Fantastic!
ps. so off to work :(
----- Original Message -----
From: "Stephen Pair" <email@example.com>
Sent: Monday, December 09, 2002 9:26 AM
Subject: RE: [Squeakfoundation]WeakMessageSends/Events for 3.4
> > Finally, I would really like to see ConnectionHandler,
> > SocketStream and BufferStream in the base, mainly
> > ConnectionHandler. These have been well vetted.
> > SocketStream may be eclipsed by the Network rewrite or flow, or
> > both...but ConnectionHandler remains useful (Trying to
> > build support for
> > streaming mp3s certainly shows the usefulness of the flow model).
> I certainly agree that ConnectionHandler is a useful class (after all, I
> wouldn't have written it if I didn't), however, I still contend that
> this and other features belong on SqueakMap, not in the base image.
> Throwing stuff like this into the base image is how we got in trouble in
> the first place.
> However, I certainly agree that some packages are too big and should be
> decomposed into their constituent parts. Comanche is probably one of
> What I would suggest (and I'm probably going to start doing this at some
> point in the future myself) is that you (and others) start publishing
> your own Squeak image...and do it through an automated nightly job that
> pull the updates off the stream, collects all of the packages that you
> want in the image, runs any Sunits, etc.
> This will be useful in a number of ways:
> a) it will serve you by having an image readily available with
> exactly the things you want in it
> b) it will serve the community by making that available
> c) it will keep you disciplined in the sense that any changes
> you want included in your base image will be factored out and separately
> d) it will serve the community because it will be exercising a
> lot of code (and probably Sunits) on a daily basis (if anything breaks
> in your build, we'll all know right away)
> e) it will serve you because if anything does break your build,
> you can point to exactly what change caused it to break, alert the
> people involved, and get them to change their code to accommodate your
> The thing missing here is the automated part...but that can come with
> - Stephen
> Squeakfoundation mailing list