Some CDS entries may contain information that is immediately useful or meaningful to applications. Other entries may contain RPC information that enables application clients to reach application servers; that is, binding handles for servers, which are stored and retrieved using the RPC NSI routines. In either case, the entry's name should be a meaningful identification label for the information that the entry contains. This is because the namespace entry names are the main clue that users and applications have to the available set of resources in the DCE cell. Using the CDS namespace to store and retrieve binding information for distributed applications is the function of DCE RPC NSI.
In general, applications can store data into CDS object entry attributes in any XDS-expressible form they wish. Refer to the tables in Attribute and Data Type Translation for XDS-to-CDS data type translations. If you add new attributes to the /opt/dcelocal/etc/cds_attributes file, together with a meaningful CDS syntax (that is, a data type identifier) and name, then the attribute is displayed by cdscp show commands when executed on objects containing instances of that attribute.
There are three main questions to consider when using CDS to store data through application calls to XDS:
1. Where in the CDS namespace should the new entries be placed?
You are free to create new directories as long as you do not disturb the namespace's configured structure. Keep in mind that CDS directories must be created with the cdscp command; they cannot be created by applications.
Only two root-level directories are created at configuration: hosts and subsys. Applications should not add entries under the hosts tree; the host's default profile should instead be set up by a system administrator. The subsys directory is intended to be populated by directories (for example, /.:/subsys/dce) in which the servers and other components of independent vendors' distributed products are accessed. Thus, the typical cell should usually have a series of root-level CDS directories that represent a reasonable division of categories.
One obvious division could be between entries intended for RPC use (that is, namespace entries that contain bindings for distributed applications), and entries that contain data of other kinds. On the other hand, it may be very useful to add supplementary data attributes to RPC entries in which various housekeeping or administrative data can be held. In this way, for example, performance data for printers can be associated with the print servers' name entries. You can either add new attributes to the server entries themselves, where, for example, the following is the name of a server entry that receives the new attributes:
/.:/applications/printers/pr1
Or you can change the subtree structure so that new entries are added to hold the data, the server bindings are still held in separate wholly RPC entries, and each group of entries is located under a directory named for the printer:
/.:/applications/printers/pr1 -- directory
/.:/applications/printers/pr1/server -- server bindings
/.:/applications/printers/pr1/stats -- extra data
In general, the same principals of logic and order that apply to the organization of a file system apply to the organization of a namespace. For example, server entries should not be created directly at the namespace root because this is the place for default profiles, clearinghouse entries, and directories.
The following figure illustrates some of the preceding suggestions, added to the initial configuration namespace structure shown in the figure, The Cell Namespace After Configuration . In the following figure, the vendor of the xyz subsystem has set up an xyz directory under /.:/subsys in which the system's servers are exported. This cell also has an /.:/applications directory in which the printers directory contains separate directories for each installed printer available on the system; the directory for pr1 is illustrated in the figure. In the pr1 directory, server is an RPC entry containing exported binding handles, and stats is an entry created and maintained through the XDS interface.
A Possible Namespace Structure
2. How should the entries be constructed?
Because CDS allows you to add as many attributes as you wish to an object entry, it is up to you to impose some restraint in doing this. In view of the XDS overhead involved in reading and writing single CDS attributes, it makes sense to combine multiple related attributes under single entries (that is, in the same directory object) where they can be read and written in single calls to ds_read( ) or ds_modify_entry( ). This way, for example, you only have to create one interface input object (to pass to ds_read( )) to read all the attributes, which you can do with one call to ds_read( ). You can then separate out the returned subobjects that you are interested in and ignore the rest. XDS and the DCE Cell Namespace describes how contains detailed discussions of XDS programming techniques.
In any case, you should define object types for use in applications so that namespace access operations can be standardized and kept efficient. A CDS object type consists of a specific set of attributes that belong to an object of that type, with no other attributes allowed. Note again that CDS, unlike GDS, does not force you to do things this way. You could theoretically have hundreds of CDS object entries, each of which would contain a different combination of attributes.
3. Should a directory or an entry be created?
When you consider adding information to the namespace, you can choose between creating a new directory, possibly with entries in it, or creating simply one or more entries. When making your decision, take into consideration the following:
a. Directories cannot be created using XDS; they must be created using administrative commands. Directories are more expensive; they take up more space and take more time to access. However, they can contain entries and can therefore be used to organize information in the namespace.
b. Entries can be created using XDS and they are cheaper to create and use than directories. However, they must be created in existing directories, and cannot themselves contain other entries.