Developer Guidelines¶
The following practices are recommended to all developers. The aim is to reduce the number and extent of any updates that may be necessary.
- The order of elements within the interface data and messages may change, within the constraints of the interface specification. Developers should avoid unnecessary dependence on the order of elements to interpret information exchanged with VOSS-4-UC.
- New interface methods, operations, actions, requests, responses, headers, parameters, attributes, other elements, or new values of existing elements, may be introduced into the VOSS-4-UC interfaces. Developers should disregard or provide generic treatments where necessary for any unknown elements or unknown values of known elements encountered.
- Notifications, operations, methods, actions, requests, responses, headers, parameters, attributes, and other elements from previous versions of VOSS-4-UC interfaces, will remain, and will maintain their previous meaning and behavior to the extent possible and consistent with the need to correct defects.
- Applications should not be dependent on interface behavior resulting from defects (behavior not consistent with published interface specifications), since the behavior can change when defects are fixed.
- The use of deprecated methods, operations, actions, handlers, requests, responses, headers, parameters, attributes, or other elements should be removed from applications as soon as possible to avoid issues when those deprecated items are removed from VOSS-4-UC or its interfaces.
- Application Developers should be aware that not all new features and new supported devices (for example, phones) will be forward compatible. New features and devices may require application modifications to be compatible or to make use of the new features or devices.
