This section presents specific design advice on the most significant components of a rad module. Naming is addressed separately in Naming Guidelines
APIs are the primary deliverable of a rad module. They are a grouping of interfaces, events, methods and properties which enable a user to interact with a subsystem.
When exposing the elements of a subsystem consider carefully how existing functions can be grouped together to form an interface. Imperative languages, such as C, tend to pass structures as the first argument to functions, which provides a clear indicator as to how best to group functions into APIs.
Methods provide mechanisms for examining and modifying administrative state.
Consider grouping together existing native APIs into aggregated rad functions which enable higher order operations to be exposed.
Follow established good practice for RPC style development. rad is primarily for remote administration, and avoiding excessive network load is good practice.
Make sure to define an <error> element with properties which can be modified.
The module is responsible for providing a sequence number. Monotonically increasing sequence numbers are recommended for use, since these will be of most potential use to any clients.
Consider providing mechanisms for allowing a client to throttle event generation.
Carefully design event payloads to minimize network load.
Don't try to replicate the functionality of network monitoring protocols such as SNMP.
All method invocations in rad are synchronous. Asynchronous behavior can be obtained by adopting a design pattern that relies on the use of events to provide notifications. Refer to Synchronization for more details.
Do not duplicate code from existing CLIs. Instead, consider moving common code into a lower library layer that can be shared by rad and the CLI.
rad modules are designed to have a language agnostic interface. However, you might want to provide additional language support through the delivery of a language-specific extension. This type of deliverables should be restricted in use. The main reason for their existence is to help improve the fit of an interface into a language idiom.