[SM]Plan...
goran.krampe at bluefish.se
goran.krampe at bluefish.se
Tue Aug 3 12:09:03 UTC 2004
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
More information about the Squeak-dev
mailing list
|