I was testing the case where the TurboFloat Server has not been upgraded to 4.0.9.7 yet (it is at 3.5.6), but the TurboFloat library is at 4.0.9.6. In this case, calling Native.TF_RequestLease returns TF_FAIL. I know it should be an error, but I don't think this is the correct error- shouldn't it be TF_E_UPGRADE_LIBRARY?
Is this expected behavior or an error? I would like to give the users an appropriate error message in this scenario.
>> "shouldn't it be TF_E_UPGRADE_LIBRARY?"
Yes, but unfortunately TF 3.x didn't have that error code. So it can't return it. So instead, it will just return a generic failure if you're trying to use newer features not available on older version of the TurboFloat library.
Still seems strange to me, since the TurboFloat library certainly would have that error code, since it is at 4.0.9.6. Or are you saying that the error code comes from the turbofloat server itself?
The error code was created in 4.0 with knowledge that in the future we might add features in the TurboFloatServer that 4.0 of the TurboFloat Library might not understand. We only came to that realization once we added features to 4.0 TFS that 3.x version of the TurboFloat Library didn't understand (namely, per-seat or named-user licensing).
If we could go back in time and write that error code into the TurboFloat Library 3.x we would. But we can't, so when TF Library 3.x sees something it doesn't understand it gets a simple TF_FAIL. Whereas when TF Library 4.x+ sees something it doesn't understand it will get TF_E_UPGRADE_LIBRARY.
Hopefully I'm not beating a dead horse here, but I'm using TurboFloat library 4.0.9.6. So by your statement in the second paragraph, it should be responding with "TF_E_UPGRADE_LIBRARY", correct? We aren't talking about any sort of advanced features here, just Native.TF_RequestLease. In this situation, the TurboFloat Library is newer than the TurboFloat server.
Or do I have it backwards? That is, is TF_E_UPGRADE_LIBRARY fired only when the TurboFloat Library is too old for the TurboFloat server?
Oh, ok, I was misunderstanding you. I thought you were using the old version of the library but the new version of the TFS. I misread it. You're doing the opposite.
Long story short: the TFS has to be upgraded first. It supports all versions of the TurboFloat Library. The TurboFloat library always assumes it's talking with a new-as or newer version of the TurboFloat Server.
Now that we are on the same page, I would think that there should be a separate exception type just for this situation, so that we can better inform the user about why they can't open their program. Because just because it won't work doesn't mean that users may not try to do it anyways. In particular, since our application can auto-update itself if the IT staff enabled that option, then the application might update before the IT staff get around to updating the TF server. We can try to prevent this by releasing the TF server a while before we release a version of our app that has the latest TF library. However, given my experience of IT people, there are a few of them that may not bother to update the TF server until they are forced to by users having errors. Make sense?
Any response on this?
We'll consider adding something like this in the future. It's impossible to add ex post facto, though (by the very nature of the products).
