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@netjam.org www.netjam.org [|] Proceed for Truth!