Levente Uzonyi wrote on Thu, 11 Mar 2010 01:03:49 +0100 (CET)
[yes, I am having problems keeping up with the current squeak-dev
traffic]
> On Wed, 10 Mar 2010, keith wrote:
> > Having a kernel image is essential if the forking problem is to be turned 
> > into an opportunity, rather than a pain.
> 
> I don't think anyone would like to make new forks in the near future 
> (except for Jecel). It's easier to cooperate than to do everything 
> on your own.

Hmmm, it seems I gave the wrong impression. First of all, we should
define "fork". Normally we think of development as a tree with a "trunk"
of a sequence of official versions and some sideways branches that we
consider to be forks. I am a bit more radical and say that a newer
version in the trunk can also be considered a fork. If some application
works in Squeak 3.7 but breaks when loaded into Squeak 3.8, then I
consider the latter to be a fork even if there are no sideways branches
(though now there is - Cuis is from Squeak 3.7, right?).

There are two ways to deal with this situation: 1) you can keep working
in 3.7 and sometimes harvest compatible bug fixes from newer versions or
2) you can change the application so that it does run in 3.8 (should be
easy enough - mostly changing some class names and eliminating a
"squeakToIso" and similar here and there). Option 2 results in an
application that will now break when loaded into Squeak 3.7, so a fork
in the environment forces a fork in the applications.

Now the transition from Squeak 3.7 to 3.8 won't feel at all like a fork
if everybody moves nearly at once and you can update from within a
running image. If enough people stay behind or if you need the
SystemTracer to get from the old image to the new then it will easier to
see that it is a fork.

Things get really annoying if you have one application that runs only in
3.7 and another that only works in 3.8 and you need to use both.
Obviously, you can just open up two Squeak windows on your machine. You
can even copy/paste between the two for some very limited and crude
collaboration between the two. A more sophisticated solution would be to
install in each image some distributed system package, like rST. If the
two images could reference each other's objects and send messages to
them, then you could do almost anything that you could do with both
applications inside a single image. At some point the differences would
leak between the two systems and things would break, but I think you
would be able to get enough extra things done in this system to be worth
doing this.

We could avoid having two or more native windows if one of the images
had some system of combining the GUIs from others (like
http://swikis.ddo.jp/SeeThroughTalk).

So if we have multiple communicating images, we will be able to handle
forks to some extent. A VM could even handle both images with the
current image format and with the very different ObjectMemory I talked
about at the same time (or a pair of VMs could do the job). This would
allow new code to take advantage of old stuff, which is something I am
very interested in. Would the new code be a fork? That depends on how
many people adopt it or not.

-- Jecel