Date: Thu, 28 Mar 2024 18:59:28 +0000 (UTC) Message-ID: <2126081634.24623.1711652368839@ae5f4610bf64> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_24622_1525229073.1711652368839" ------=_Part_24622_1525229073.1711652368839 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The Ice message form= at is governed by two sets of rules: the protocol rules and the encodin= g rules. The protocol rules define the number of message types as well as t= he format of the message headers. The encoding rules specify how Slice type= s are marshaled. Ice maintains separate versions for the protocol and encod= ing, which makes it possible for them to evolve independently.
Several of the new features in Ice 3.5 require changes to the way t= hat Slice classes and exceptions are marshaled. These changes make the enco= ding 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 ne= cessitated 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 releas= e.) We took advantage of this opportunity to make some other minor imp= rovements 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, appli= cations that use version 1.0 of the Ice encoding. Ice 3.5 uses the followin= g semantics:
=
Ice.Default.EncodingVersion
property.