TS PADI - General Overview of Available Software

The protocol has two somewhat distinct uses. The first usage is to supply data to several users' client programs from databases which are available for many users to access (usually in a read only mode). This uses what is called a "public mode" server below. The second usage is to provide a mechanism for a single user to pass data from one program to another by writing it to a data base and then retrieving it. This usage is implemented by what is called a "local mode" server below. The reason for providing both types of usage is so that other interfaces can be eliminated, and support costs reduced.

On the client side the requests do not depend on the mode of the server. The main features of the protocol are illustrated by the programs getpadi and putpadi, which are provided as part of the "generic client" described below. The client programs getpadi and putpadi will retrieve and write (if allowed) data on a server which is already running. A public mode server would typically be in continuous operation, so no other steps are required. To support passing data between user applications, a user will first need to start a local mode server process. This can be done automatically by an application, as is illustrated in the S client implementaion.

On the server side, the getpadi and putpadi requests are handled differently by the example public and local mode Fame server implementations. For a public mode server the client programs getpadi and putpadi will retrieve and write (if allowed) data on a server which is setup to provide specific databases. A local mode server allows the client to specify a database which the server will need to open. In this case, any database to which the server has accessed can be loaded.

The protocol passes an argument called database which may be used or ignored by the server implementation. Database is used here in a very generic sense. The protocol only sends a character string from the client to the server. The server implementation might use this string in many different ways. In the example Fame implementation database is ignored by the public mode server and in the local mode server it is used to indicate a file for Fame to open. In the example simple server implementation database is used to indicate a subdirectory where files for each object (series) will be stored.

The protocol also passes arguments called user and password which may be used or ignored by the server implementation. In the examples user is used only to avoid conflicts between local mode servers and password is not used at all.

PADI is available as C code and uses the RPC utility. Versions of RPC are available for most platforms.

A quickly growing number of venders are now considering supporting this protocol in their products. Please contact your vendors before attempting to add an interface to a product you use. They may already be doing the work for you.

Protocol Software

The protocol communicates the data and the information required to reconstruct the time series object. The difficulty here is to provide a format which is general enough to map between programs which may have very different conventions for representing time series data. The following conventions attempt to accomplish this (but this is the area which is most likely to require further refinement in future implementations):

• Dates are passed as a string in the format yyyymmdd, e.g.: "19950322". For non-daily data these would typically represent a reference time in the period. (For example, the fame server translates the date to the last day of the period.) Partial dates are accepted, in which case the protocol infers the 1st month and/or day for the missing portion (e.g. "19950101" is inferred from "1995" - but then if this is for annual data Fame will convert it to Dec. 31, 1995, and it would be returned as "19951231").
• The frequency is passed as a string and a client or server can work only with a set for which it has a definition. The example clients (generic.client and S.client) only understand frequencies which start with "ANNUAL, "QUARTERLY", "MONTHLY", and "WEEKLY". These are translated in the example client software to 1, 4, 12, and 52, respectively. Anything else is translated to a frequency of 0. The fame server supports a much wider range of possiblities. These can be seen by looking at the definition of freqname_t in fame_svc.c. Many of these are not distinguished by the example clients (e.g. "WEEKLY(MONDAY)" is translated to 52 by the example client software.)
• The client can request the values which are to be returned for "Not Computable", "No Data", and "Not Available". This provides the client with a consistent result when contacting different servers. In the example clients these are set to:

  Not Computable

  170141345719746060945050695293894393856.000000

  No Data

  170141670238299719371777478449914970112.000000

  Not Available

  170141507979022890158414086871904681984.000000

  In the S client these are then converted to the S Inf, NA and NA indicators respectively.