-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
backward compatibility with release-2.0 #110
Comments
It would be better to avoid complicating the GUI with more options (and the additional development and maintenance work). Why is it a problem for the server that it receives a v2 message if it only supports v1? Shouldn't the server just drop the v2 message? |
In any openigtlink applications, they use : you can test slicer 4.11 with ImageDatabaseServer build from release2.0 to verify the error. |
The unpack process in the release 2.0 can be modified to NOT checking the header version, which is the case for later releases. |
We upgraded from Slicer 4.8 to 4.11 and had two issues. We wrote our own code on client (robot) side, and had to update. |
I tested the SlicerOpenIGTLink with the example programs(TrackingData/ImageDatabaseServer) in openigtlink release-2.0. I need to run these commands in slicer python interactor before active the connector:
During the initial handshake with TrackingData/ImageDatabase servers, the connector sends a dummy status message to check openigtlink version of the server. if the SetOutgoingMessageHeaderVersionMaximum is not set, the dummy message will be header version 2 by default and the parsing will fail at the server side. The failure of parsing the status message propagate to following messages resulting no communication at all.
Should we have a UI component to set the maximum version of the Outgoing Message Header?
Thanks!
The text was updated successfully, but these errors were encountered: