PreviousNext

The dced Programs Maintains Entry Lists

One dced service's data is very different from another's (for example, server configuration data versus key table data), but you manipulate the data in a similar way. This is because it is a simpler and more efficient design to implement a few API routines that can handle more than one kind of data rather than many routines that do essentially the same thing but on a different service's data. An added benefit is a flexible API that can handle your own application's data and new kinds of DCE data in the future.

To separate the actual data from the API implementation, a dced service maintains a list of all data items in an entry list. Entry lists contain entries that describe the name and location of each item of data, but they do not contain the actual data. With this mechanism, dced can obtain and manipulate data very efficiently, without concern for the implementation and location of the actual data. It also supports well the model that administrators commonly need when accessing data: scan a list, select an item, and use the data.

The dced program maintains entry lists for the hostdata, srvrconf, srvrexec, and keytab services. The secval service does not need an entry list because it does not maintain any data, but functions are performed to set its state.

There is a special relationship between srvrconf and srvrexec entries. In order for dced to control the start of a server, the server must have a srvrconf entry associated with server configuration data. When dced starts a server, it generates from the srvrconf entry and data a srvrexec entry and associates the new entry with the running server's state.

The following figure shows the entry lists maintained by dced.


The dced Entry Lists

Although an entry can be associated with many different kinds of data items, all entries have the same structure, shown in the following figure.


Structure of an Entry

Each entry is a dced_entry_t data structure. Each member of this data structure is described as follows:

id
An entry UUID is necessary to uniquely identify the data item. Some data items have well-known UUIDs (the same UUID for the particular item on all hosts). The data type is uuid_t.

name
Each data item is identified with a name, to which applications refer. The name need only be unique within an entry list because the entry UUID guarantees the entry's uniqueness. Some item names are well-known and defined in header files. The data type is dced_string_t.

description
This is a human-readable description of the data item. Its data type is dced_string_t.

storage_tag
The storage tag locates the actual data. Each service knows how to interpret this tag to find the data. For example, some data is stored in a file, the name of which is contained in the storage tag. Other data is stored in memory and the storage tag contains a pointer to the memory location. The data type is dced_string_t.