The Ice message format is governed by two sets of rules: the protocol rules and the encoding rules. The protocol rules define the number of message types as well as the format of the message headers. The encoding rules specify how Slice types are marshaled. Ice maintains separate versions for the protocol and encoding, which makes it possible for them to evolve independently.
Several of the new features in Ice 3.5 require changes to the way that Slice classes and exceptions are marshaled. These changes make the encoding incompatible with previous releases, therefore Ice 3.5 also introduces version 1.1 of the Ice encoding. The protocol remains unchanged at version 1.0.
The following improvements to the encoding for classes and exceptions necessitated the new version:
Changing the protocol or encoding format can be disruptive and does not happen often. (In fact, this is the first change since Ice's initial release.) We took advantage of this opportunity to make some other minor improvements that have been on our "wish list" for some time.
Naturally, these changes raise the issue of backward compatibility with applications that use earlier versions of Ice, and more specifically, applications that use version 1.0 of the Ice encoding. Ice 3.5 uses the following semantics:
- Encoding version 1.1 is the default for Ice 3.5. You can change this default using the
Ice.Default.EncodingVersionproperty. - A proxy is marshaled with an embedded encoding version representing the highest version supported by the target object, so the receiver of a proxy always knows the encoding version(s) it is allowed to use when invoking operations on that proxy. A proxy created locally uses the default encoding version, which can be inspected and changed using proxy methods.
- The results of an operation are encoded using the same version as the incoming request.
- As you would expect, the features provided by the 1.1 encoding are unavailable when an Ice 3.5 application is forced to use the 1.0 encoding.