Next: Designing for future compatibility
Up: KADM5 Library and Server
Previous: API Handles
Contents
The KADM5 system is designed to support multiple versions of the KADM5
API. Presently, two versions exist: KADM5_API_VERSION_1 and
KADM5_API_VERSION_2. The former is equivalant to the initial
OpenVision API, OVSEC_KADM_API_VERSION_1; the latter was created
during the initial integration of the OpenVision system into the MIT
release.
Implementing a versioned API in C via with both local and RPC access
presents a number of design issues, some of them quite subtle. The
contexts in which versioning considerations must be made include:
- Typedefs, function declarations, and defined constants depend on
the API version a client is written to and must be correct at compile
time.
- Each function in the server library must behave according to the
API version specified by the caller at runtime to kadm5_init_*.
- The XDR functions used by the RPC layer to transmit function
arguments and results must encode data structures correctly depending
on the API version specified by the client at runtime.
- Each function in the client library must behave according to the
API version specified by the caller at runtime to kadm5_init_*.
- The RPC server (kadmind) must accept calls from a client using
any supported API version, and must then invoke the function in the
server library corresponding to the RPC with the API version indicated
by the client caller.
- When a first API function is invoked that needs to call a second
function in the API on its own behalf, and that second API function's
behavior depends on the API version specified, the first API function
must either be prepared to call the second API function at whatever
version its caller specifies or have a means of always calling the
second API function at a pre-determined version.
The following functions describe how each context is handled.
Subsections
Next: Designing for future compatibility
Up: KADM5 Library and Server
Previous: API Handles
Contents
Autobuild
2009-09-05