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..
"Chris Muller" ma.chris.m@gmail.com wrote:
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.
Ehm, did you just say that Magma doesn't work with 3.8?
Gjallar has been focused on 3.8 since we use quite a whole big bunch of libraries and 3.8 felt like the most stable and spread platform. I haven't investigated jumping ahead to 3.9, it may be doable.
[SNIP]
If you are still with me, thank you. The point of all this is I would like to know how others feel about:
- 3.7 compatibiltiiy at all
Not interesting for us/me. At this point in time I feel that 3.8 is the oldest still important platform. But that is just me.
- mixing 3.8 and >3.8 images
Doesn't sound that useful - and definitely not for Gjallar.
- the desire to use Blocks, CompiledMethods or Processes in your persistent model
Blocks could be useful - but currently we don't. I have a hard time seeing the others being used - CompiledMethod could be interesting if Magma was to be used for storing precompiled code in some SCM solution or such.
- the risks of adding all those honkin' classes above to the
protocol just to support executeInServer:.
Well, we need those darn numbers. :) Or rather - we need the illusion of a very large OrderedCollection that can be added to from multiple sessions. Of course interested in hearing about alternatives.
Thanks..
regards, Göran
Hi Göran,
On 9/1/07, goran@krampe.se goran@krampe.se wrote:
"Chris Muller" ma.chris.m@gmail.com wrote:
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.
Ehm, did you just say that Magma doesn't work with 3.8?
Yeah, I didn't test it in 3.8 but having added MethodProperties to the protocol without even checking whether its present in the image will need to be improved.
Right now my thought is to convert this solution that was done for r41Alpha1 (NOT release 40) from remoteEvaluate: aBlock to remotePerform: selectorSymbol with: anObject. "anObject" would have to be one in the protocol, of course and, for yours, I think it would/could be. This would eliminate the need for all that extra protocol for just one feature.
- 3.7 compatibiltiiy at all
Not interesting for us/me. At this point in time I feel that 3.8 is the oldest still important platform. But that is just me.
I know at least Avi has mentioned using a stripped down 3.7 for DabbleDb, so I know there is SOME interest in still using 3.7. Whether there is any overlap in that group and the group interested in using Magma, I'm not so sure. :/
- the desire to use Blocks, CompiledMethods or Processes in your persistent model
Blocks could be useful - but currently we don't. I have a hard time seeing the others being used - CompiledMethod could be interesting if Magma was to be used for storing precompiled code in some SCM solution or such.
Yeah, and I forgot to mention SortedCollections..
- the risks of adding all those honkin' classes above to the
protocol just to support executeInServer:.
Well, we need those darn numbers. :) Or rather - we need the illusion of a very large OrderedCollection that can be added to from multiple sessions. Of course interested in hearing about alternatives.
Sure. At worst we'll at least port to the remotePerform: solution instead of remoteEvaluate. We'll still have the compatibility issues between Squeak versions w.r.t. the persistent model, but at least not with the client-server protocol (which is much worse).
- Chris
magma@lists.squeakfoundation.org