API RPC Change History

This chapter contains summaries of changes made to API RPC protocol in each version of Parallels Plesk Panel.

The changes are listed with the most recent first. The next paragraph explains how these changes are grouped.

Changes are first grouped by Plesk version, and then are divided into two categories:

• Changes made to the latest protocol version as compared to the previous one (subsection named according to the protocol version, e.g., 1.6.0.2)
• Changes to earlier versions of the protocol caused by changes in logic of a new Plesk version (subsection Changes to Earlier Versions).

These two groups are further categorized by Plesk features that required modifying operators and/or operations. Each set of feature-dependant changes is fit into a separate table and sequenced in alphabetical order.

Thus, if you use Plesk 9 through API RPC 1.5.0.0 and want to see changes to API RPC 1.5.0.0 driven by the Plesk 9 backward compatibility feature, refer to subsection Plesk 9 > Changes to Earlier Versions, table "Feature: Plesk 9 backward compatibility".

Each feature-dependant table consists of the following columns:

• Option - defines whether an operator/operation/parameter is added ("+"), modified ("*"), or deprecated ("-").
• Operator - contains the name of the operator affected by the feature.
• Operation - contains the name of the operation affected by the feature. The operation name is omitted in the following cases:
  • New operator is added
  • Operator is removed
  • Feature modifies the behavior of an entire operator
  • Feature modifies the XSD complex type that is not explicitly related to an operation (Example: filters).
• Type/File - contains the name of an XSD complex type affected by the feature. This name helps to determine whether request, response or both packet structures are changed. If the complex type name is changed, the new name is given. If an operation description is changed, and new description does not use any named complex types, the XSD file which contains the operation description is given. The type/file name is omitted in the following cases:
  • Operation description is left unaffected.
  • Operation is added or deprecated.

    Note: The summary of changes does not explicitly track changes in complex type names

• Parameter - contains the affected parameter. This value is present only if Operation or Type/Filename values are provided. If the operation name or both values are set, the path to the parameter is given relatively the operation node. Otherwise, the path is given relatively to the XML element described by the type. We use XPath notations to address the parameter.
• Comment - contains short description of a change. In case an operator, operation or parameter is deprecated, this field contains brief instructions on what functionality can be used instead.