1.3 Preliminary Design Precis (Phase I)

The materials in the previous chapter are the original specification inputs to the project.

From them I have synthesized a design using established best practices, specifically the application of analysis and design patterns^[1],[2],[3], and concept checking templates ^[4].

Clients communicate with a call level interface or API at the server using XMLRPC but a client thru with which they can use the API locally at the logical level without having to form XML or manage RPC is provided.

xmlrpc-c provides via introspection a capability to generate the client interfaces for C and C++ are these are used to generate same for this project. Others I have identified current at this writing for perl and python, but there are competitor packages which can be used for most languages with additional developer effort^[7].

By maintaining compatibility with the stable baseline of xmlrpc-c clients and tools in our design, the implementation is immediately usable by developers in those languages. However this project is limited to the C/C++ interfaces.

Portions of the server and client are derivatives of the current xmlrpc-c advanced level package adapted for this design so the design immediately recovers and applies that functionality to the requirements.

While the API level traffic will be using XMLRPC between the clients and the master daemon and TCP sockets, a second level of communication between the client and the server will be used to maintain telemetry on the observables. While the time domain of this latter UDP layer will be maintained as a design criteria in the few 100s of microseconds, the processing of API level requests depends on the API, real conditions in the process etc. This will vary from a couple of orders of magnitued greater for some simple API to indefinite for those which are event driven.

The programming of both the client and server will be generic with specific assignments of meaning either at program load time from XML text in the configuration directory or dynamically using the API during run time.

The mapping of the contract deliverables to the specification are given in a chapter in part 5 of this document.