Running Magma across different Squeak versions

[Chris Muller]

Hi Göran,

On 9/1/07, goran at krampe.se <goran at krampe.se> wrote:
> "Chris Muller" <ma.chris.m at 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.

> >  1) 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.  :/

> >  3) 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..

> >  4) 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