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
|