Running Magma across different Squeak versions

Chris Muller ma.chris.m at gmail.com
Sat Sep 1 04:19:12 UTC 2007


Magma has very little special-case code for its code-base to maintain
compatibility across a variety of Squeak images; 3.7, 3.8, 3.9,
Croquet, base Tweak, squeak-dev and soon (if not already) 3.10.

Yesterday the Gjaller team contacted me about a function they needed
from Magma; generation of a continuously-increasing sequence number
with no chance for a duplicate between any two clients.

Today I augmented Magma with a scary solution to the problem,
MagmaSession>>#executeInServer: aBlock.  I've said there are caveats
to this and now I would like to elaborate.

To make this work I had to add the following classes to the #protocol
(which you can observe by browsing the changes between Magma
server-cmm.229 and Magma server-cmm.230).

       "Classes for serializing the codeBlock of a MaServerExecuteRequest"
        {MaBlockContextStorage . MaMethodContextStorage .
MaCompiledMethodStorage . DiskProxy . MethodProperties . BlockContext
. ContextPart . InstructionStream}

Magma has enjoyed its wonderful compatibility and ease of migration
thanks to staying mostly above the meta-layer.  But you can see that
by introducing these to the protocol in this way, we have already
broken compatibility with 3.7 and 3.8, which do not include
MethodProperties.

I then wondered whether a Magma server on any squeak version could
host a variety of clients of different versions.  I tested it as soon
as I got home, here's what I found:

 - There appears to be problems going between 3.7 and >3.7 images due
to the introduction of ByteString in place of String.
 - 3.8 and 3.9 seem to work together, except for CompiledMethods due
to, once again, the aforementioned MethodProperties.

If you are still with me, thank you.  The point of all this is I would
like to know how others feel about:

 1) 3.7 compatibiltiiy at all
 2) mixing 3.8 and >3.8 images
 3) the desire to use Blocks, CompiledMethods or Processes in your
persistent model
 4) the risks of adding all those honkin' classes above to the
protocol just to support executeInServer:.

Thanks..


More information about the Magma mailing list