Client Compatibility
3 answers
Yes, this is expected ... you will be able to use 3.0 clients with 3.0.1
servers, but you will not be able to use 3.0.1 clients with 3.0 servers
(i.e. you are expected to upgrade the server first, and then the clients).
Note: The first time I noticed this was when I upgraded to the M13 client.
Cheers,
Geoff
On 3/14/2011 8:23 AM, luciano wrote:
servers, but you will not be able to use 3.0.1 clients with 3.0 servers
(i.e. you are expected to upgrade the server first, and then the clients).
Note: The first time I noticed this was when I upgraded to the M13 client.
Cheers,
Geoff
On 3/14/2011 8:23 AM, luciano wrote:
Hi,
I downloaded the newest RTC Client 3.0.1 M13 and tried to connect to
our server running on 3.0. It failed with a client and server
mismatch. Is this behavior intended?
Thanks,
Luzi
It's interoperability and code complexity.
For maximal interoperability, you'd want every rich client version to be
able to interoperate with every server version. This would require
that every place a rich client takes advantage of (or be compatible
with) new server functionality, that it have an extra code path ... one
for the old server and a revised one for the new server. In many cases,
the change to take advantage the new functionality is quite extensive.
In addition, verifying that all the cross-rev scenarios work adds
significantly to the testing load. So that all can be done, but it is
traded off directly against requested new features.
So the compromise is to provide enough interoperability that a customer
has an incremental upgrade path: upgrade servers first, and then upgrade
the rich clients when the new functionality is desired by the user of
that client. A user that interoperates with multiple servers at
different levels has the option of using a single rich client at the
lowest compatible level, or to keep several rich clients for
interoperating with different servers.
And of course, for many use cases, the user would just be using the web
client and not have to worry about client version compatibility.
Cheers,
Geoff
On 3/15/2011 4:08 AM, luciano wrote:
For maximal interoperability, you'd want every rich client version to be
able to interoperate with every server version. This would require
that every place a rich client takes advantage of (or be compatible
with) new server functionality, that it have an extra code path ... one
for the old server and a revised one for the new server. In many cases,
the change to take advantage the new functionality is quite extensive.
In addition, verifying that all the cross-rev scenarios work adds
significantly to the testing load. So that all can be done, but it is
traded off directly against requested new features.
So the compromise is to provide enough interoperability that a customer
has an incremental upgrade path: upgrade servers first, and then upgrade
the rich clients when the new functionality is desired by the user of
that client. A user that interoperates with multiple servers at
different levels has the option of using a single rich client at the
lowest compatible level, or to keep several rich clients for
interoperating with different servers.
And of course, for many use cases, the user would just be using the web
client and not have to worry about client version compatibility.
Cheers,
Geoff
On 3/15/2011 4:08 AM, luciano wrote:
Thanks for the clarification. Is there a technical reason for this
behavior?