Hi all--

	Avi writes:

> I've advocated this in the past without any success, but I might as
> well try again: the way to get people to adopt Flow is to make it
> possible for them to use it side by side with the existing streams,
> so that they can migrate to it incrementally without anything needing
> to be broken during the process.

	(I've said the following before as well. :)

	In August 2002, when I released Flow for Squeak 3.2, I decided that,
rather than continuing to chase the moving target of the conventional
accretive-growth snapshot (AKA the Bloat snapshot :), it'd be better to
solve the modularity and minimal-core problems first. So, that was the
last release of Flow I made for the conventional snapshot, and I started
the Squat project ( http://netjam.org/squat ). In the meantime, I
encouraged people to do port things to use Flow in a separate snapshot
(e.g., the one I provided in the Flow release). I didn't agree that
everything old and new should have to run at the same time in the same
snapshot, during the porting process.

	I hope it's clear that I'm no longer trying to get Flow into the Squeak
1, 2, or 3 series; I gave up on that in 2002. Instead, I'm helping to
attack the more fundamental issue of developing a minimal core into
which one may load modules. Ideally, that will be Squeak 4 or 5
(depending on the timing of other pent-up features like the new compiler
and compiled method format). Then, I can release Flow as an optional
module (and not as changesets or other static artifacts). (The Squat
minimal snapshot does use a few elements of Flow, but they can be
unloaded; I don't think Squat's partial use of Flow for bootstrapping is
a salient point in this discussion.)

	So, to Stéphane, who writes...

> I agree with Avi. So please think about transition.

	...I respond that my transition plan is to first solve the underlying
system organization problems. I think having a minimal core and
peer-to-peer module installation will solve the problems of accretion
and name conflicts that made installing low-level frameworks like Flow
so problematic.

	When I reminded people of Flow in this thread, I didn't mean to
advocate its literal inclusion in the Squeak 3 series; I apologize if I
gave that impression. But it's true that until we've made a transition
to a minimal core, using Flow as currently released does indeed require
work (unless one wants to work in a 3.2 snapshot, which I wouldn't
expect). This just inspires me all the more to work on the minimal
system.

	There's also the matter of how my ideas for packaging jibe with those
of SqueakMap and Monticello. While I intend to address these in detail
in a different thread, the short summary is this:

	When the Guides were formed in November 2002, and the community started
trying to define the content of particular packages, I'd hoped that the
major result would be finding the boundaries between packages, without
getting too set on the form of the package artifacts. But of course,
they had to take some form, and they did. And time passed while I did
the first round of work on the minimal core and how to add to it. So, I
now find myself in the awkward position of having an alternate form to
propose, despite the fact that there are now many package artifacts in
existence in new-since-2002 "de facto" forms. I think what saves things
here are the technical aspects of what I propose (the peer-to-peer
negotiation stuff).

	But it's because of that awkward position that I intend Squat to be a
future version of Squeak if people want that, or a fork otherwise (or
rather, a Spoon :). I don't mean to imply any particular value judgement
about forking; it's just that if I'm going to share my minimal-system
work and it's not official Squeak, I shouldn't call it Squeak. :)


	thanks for reading,

-C

--
Craig Latta
improvisational musical informaticist
craig at netjam.org
www.netjam.org
[|] Proceed for Truth!