The CSA interface enables a common interface to a calendaring and scheduling service. For each CSA implementation, the view and capabilities presented by CSA must be mapped to the view and capabilities of the underlying calendaring service. The interface is designed to be independent of the actual calendaring and scheduling implementation. The interface is also designed to be independent of the operating system and underlying hardware used by the calendaring service.
The number of function calls provided is minimal. A single set of functions manage multiple types of calendar entries.
The identifier for an element of the C interface is derived from the generic name of the element and its associated data type, as specified in Table 10-1 . The generic name is prefixed with the character string in the second column of the table; alphabetic characters are converted to the case in the third column.
Table 10-1 Derivation of C Naming Conventions
Element Type |
Prefix |
Case |
---|---|---|
Data type |
CSA_ |
Lower |
Data value |
CSA_ |
Upper |
Function |
csa_ |
Lower |
Function argument |
none |
Lower |
Function result |
none |
Lower |
Constant |
CSA_ |
Upper |
Error |
CSA_E_ |
Upper |
Macro |
CSA_ |
Upper |
Reserved for extension sets |
CSA_XS_ |
Any |
Reserved for extensions |
CSA_X_ |
Any |
Reserved for use by implementors |
CSAP |
Any |
Reserved for vendor function extensions |
csa_x |
Lower |
Structure Tag |
CSA_TAG_ |
Upper |
Elements with the prefix CSAP (any case) are reserved for internal proprietary use by implementors of the CSA service. They are not intended for direct use by programs written using the CSA interface.
The prefixes CSA_XS_, CSA_X_ (in either uppercase or lowercase), and csa_x are reserved for extensions of the interface by vendors or groups. The specification defines these interface extensions as extensions to the base set of functions.
For constant data values, an additional string is usually appended to CSA_ to indicate the data structure or function for the constant data value.