Hi all!

Just thought I should explain a bit on how the SM work is proceeding. I
will be going to China (Beijing and then Guangzhou) next week and be
there for two weeks. And when I get back I will not have much time for
anything but being with my wife and our little daughter. :)

So things will be slow (well, definitely not slow for *me* :) ) for the
next 2 months, but it will not be standing still.

My current plan looks something like this:

1. Work a bit more on the dependency engine that I have and that
actually seems to work! At least enough to demo it.

2. Prepare a demo image for the dependency model and the altered SM
model beneath it. This demo image will then be available at ESUG, even
though *I* will not be.

3. Keep working with Stephan Rudlof and making sure that SM will be able
to support his "additions" to the model. See below for a quick
explanation.

4. Eventually deploy a dependency enabled 1.1 of SM that includes at
least the parts I have planned. Possibly Stephan's parts will come later
- or perhaps it will be included.


Ok, so I have postponed the architecture change of SM. Version 1.1 will
still use the current architecture with a single master server and
snapshots using ImageSegments. But it will include a working server
cache, instructions for setting up readonly mirrors, and bug fixes and
possibly one or two other things. And of course - dependencies. :)

Regarding the architecture discussions (multiple servers/universes etc)
I may have changed my plans and it would enable the use of "multiple
sources" into a single client - but I am *definitely* not sure yet, and
as I said - I am postponing these decisions until later when the model
will be clearer.

Now - how does the current dependency plan look? Well, Stephan and I are
exchanging thoughts and it looks "approximately" like this:

- We both rely on the maintainers to enter "compatibility level"
information when registering new releases on SM. My model would have
been a single drop down menu selection. Stephan's richer model would
mean a multi select list with circa 6 items in it. So both are easy
enough and we will probably go for a unified variant.

- I am focusing on "configurations" and "anti-configurations" and a
dependency engine based on those.

- Stephan adds a few other concepts to the model, especially his Caps
and Transformations.

To us it currently seems like we can experiment with both these models
in conjunction and I will make sure SM supports Stephan and his needs to
try his additions - when his design has stabilized.

Well... that was it!

And oh, here is a little pdf describing SqueakMap and it has an
interesting little graph in it, and the code I used to produce it:

	http://anakin.bluefish.se/gohu/uploads/11/squeakmap.pdf

The pdf is my little entry of SqueakMap into the "Innovation Technology
Award" at ESUG. :)

regards, Göran