Hello,
I have recently cleaned-up constants for message sizes [1], which had
the side effect of breaking new VMs (post-change) with old Studios
(pre-change). Following a comment from Philippe, I have added back a
compatibility constant [2].
I do not like this solution because it keeps old dirty hacks in. Yet I
agree that given our Thymio user base, in the current situation it is
highly probable that someone will flash a firmware with the new VM to
the Thymio from the old Studio, breaking Aseba on the Thymio.
Therefore, I think that we should have a mechanism to force a certain
version of Studio before flashing a Thymio. I propose the following:
- To release firmwares in a container, having the .hex file and a
"manifest" file, that will specify conditions (Aseba versions, etc.)
that allow flashing. For the container, we could simply use a zip file,
and use a Qt-compatible implementation of zip such as osdab-zip [3].
- To increment the versioning in the Aseba protocol, which will tell the
user to upgrade Studio. This would work even without the proper check of
the firmware, but it is quite nasty to let the user upgrade a robot with
the wrong Studio. I would also turn the current warning [4] into a fatal
error, if the node is using a more recent version than Studio, and keep
a warning if the node is using an older version (i.e. we have backward
compatibility but not forward).
What do you think?
Cheers,
Stéphane
[1]
https://github.com/aseba-community/aseba/commit/f2376db125434c3975b09c6554394ce1c2fa9cdc
[2]
https://github.com/aseba-community/aseba/commit/4292805a42e2eab45590631b126b58645eef8b55
[3]
http://code.google.com/p/osdab/downloads/detail?name=OSDaB-Zip-20120910.tar.bz2&can=2&q=
[4] studio/DashelTarget.cpp:315
--
Dr Stéphane Magnenat
http://stephane.magnenat.net
_______________________________________________
Aseba-dev mailing list
Aseba-dev@gna.org
https://mail.gna.org/listinfo/aseba-dev
