ADR Definition Document for a RAD Module

The top-level element in an ADR definition document is an api. The api element has one mandatory attribute, name, which is used to name the output files. The element contains one or more derived type definitions or interface definitions. Note that either a derived type or an interface must be defined.

Three derived types are available for definition and use by interfaces: a structured type that can be defined with a struct element, an enumeration type that can be defined with an enum element, and a dictionary type that can be defined with a dictionary element. Interfaces are defined using interface elements. The derived types defined in an API document are available for use by all interfaces defined in that document.

The following is an example of an API.

Example 2-1 Skeleton RAD Module document

<api xmlns="https://xmlns.oracle.com/radadr" name="com.oracle.solaris.rad.example" register="true">
  <summary>
    An API Example
  </summary>
  <doc>...</doc>

  <version/>

  <struct>...</struct>
  <struct>...</struct>
  <enum>...</enum>
  <interface>...</interface>
  <interface>...</interface>
</api> 

The xmlns line is required to indicate the type of the XML document. The name attribute identifies the name of the API, the namespace within which all subsidiary interfaces are to be found. Additional attributes can assist in the generation of server module code.

The register attribute is a boolean, which is optional and true by default. If true, then radadrgen automatically generates a _rad_reg function when generating server implementation code. If false, the function is not generated and the module author will need to provide a _rad_reg function. This option is primarily used to create special types of modules, such as protocol or transport modules. In general, it does not need to be specified, because the default generated function is enough for most purposes.