New SqueakMap on the air... and we got problems Houston!

Andreas Raab andreas.raab at gmx.de
Thu Apr 6 09:10:40 UTC 2006


Hi Goran,

>> It simply means that older versions of the client are capable of dealing 
>> with newer data sets coming from the server, so that the clients don't 
>> need to be updated in sync with the server. There are many good reasons 
>> for this; the most important one being that people like to be able to 
>> decide when they want to upgrade instead of being forced to.
> 
> Well, I for one don't want to have multiple versions of SM running out
> there trying to make sense of the model coming from the latest version
> running on the server. It sounds way too risky for my taste.

Well, that's like saying it's way to risky that people use different 
browsers for displaying web content and *force them* to install IE 7 
when they want to look at a random page. And "oh, by the way" one of the 
reasons why I'm in this discussion is that SM is currently just the 
icing on the cake of all the issues that I'm dealing with in the Croquet 
release. Its attempt to forcefully update itself in an environment it 
knows relatively little about only leads to problems. I'm actually on 
the verge of removing SM last minute; the way it's right now with the 
2.1 client not working and 2.2 failing to install it's really not very 
attractive to carry that much dead code around. (but I'll wait with that 
decision simply because I had a *very bad* day today and perhaps I feel 
different later).

> Ok, I understand what you mean - but I still don't like the effects. If
> we move towards an XML format (which I now really intend to do unless
> someone comes up with a brilliant alternative) then yes, we would at
> least have a sporting chance of making the client side "work" with a map
> coming from a newer server but... it would also mean that different
> images will behave differently. And it could mean that bugs will pop up
> like "oh, right, darn, didn't think of that - it works in SM 2.31 and
> 2.33+ but you are right, it would barf in 2.32".

Well, isn't that called testing?! ;-) Maybe a few tests would help to 
automate the process?! ;-)) Actually, I'm only partly kidding - it seems 
pretty clear that any version you want to support needs at least a 
rudimentary amount of support and testing but if there are people out 
there interested in a particular system I'm sure they'll give you the 
feedback you need.

> Sure, I can make the code do a "hey, this tag is odd - lets skip
> it"-kinda thing, but I still will reserve the "right" for the client to
> say - "nope, sorry, this model is too new for me, at leat the author
> thinks so - press yes to go ahead, and have fun in the debugger when SM
> trashes your image". :)

And that's perfectly reasonable, though, in my experience fairly 
unlikely if you start out with the goal of supporting future versions. 
Like, for example, the interpreter proxy - it was designed to be able to 
indicate to a plugin that it has changed beyound recognition by changing 
the major version number. And yet, even though the VM has evolved since 
the proxy was first invented, the very first plugins will still happily 
work with the very latest VMs. In other words, it's really more a 
question of *wanting* to support future versions - if you have a basic 
understanding of what your system needs to provide to a client to work 
reasonably well (and I think by now, you do have a fairly good 
understanding of that for SM) you can design things so that they still 
work tomorrow even if some parts change and evolve. The VM is proof of 
that and I'm virtually certain that SM could be designed with a very 
similar version scheme with very similar long-term properties.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list