requestTransportFilters backwards compatibility

[Jeremy Viehland]

Hi,

I've had to make the following hackish change to RCF-2.0.1.100
in order to establish a custom filter with an RCF-1.3 server:

-------------------------------------------------------------
diff -r 51a401701931 rcf/src/RCF/ClientStub.cpp
--- a/rcf/src/RCF/ClientStub.cpp Mon Jun 23 13:34:27 2014 -0400
+++ b/rcf/src/RCF/ClientStub.cpp Mon Jun 23 18:48:19 2014 +0100
@@ -955,7 +955,7 @@
return;
}

- ClientStub stub(*this);
+ ClientStub& stub = *this;
stub.setTransport( releaseTransport());
stub.setTargetToken( Token());

-------------------------------------------------------------

This copy constructor was storing the remote server version.
Because this copy was stack-constructed, information about
the remote server was thrown away, and so on subsequent
calls to `requestTransportFilters', `getRuntimeVersion' was
still returning 12 instead of the 8 from our RCF-1.3 server.
Thus, `requestTransportFilters_Legacy' was not getting called.

With this change, the first call still fails, but subsequent calls
invoke `requestTransportFilters_Legacy', which succeeds.

As far as we know, this change is working for us, but if there
are side effects that you may be aware of, please let us know.

Thanks!

[jarl]

The server version number is established the first time you make a call on a RcfClient<>. If you do a simple ping on your client:

Code: Select all

RcfClient<...> client(...);
client.getClientStub().ping();

, that will set the server version number correctly, and if you then subsequently call requestTransportFilters() , it should work as expected.

[Jeremy Viehland]

Thank you for your quick response! I have made the modification you suggested and will back-out our hack and retest.