FNS and Applications

Applications that are aware of FNS can expect the namespace to be arranged according to the FNS policies, and applications that bind names in the FNS namespace are expected to follow these policies.

Applications use FNS in the following ways:

Applications can use FNS through existing interfaces. A significant proportion of FNS use is through existing application programming interfaces. For example, consider a UNIX application that obtains a file name that it later supplies to the UNIX open() function. With FNS support for resolution of file names, the application need not be aware that the strings it deals with are composite names rather than the traditional local path names. Many applications can thereby support the use of composite names without modification.
Applications can be direct clients of the XFN interface and policies. Application-level utilities, such as the file system, the printing service, and the desktop tools (calendar manager, file manager) are examples of clients that use the XFN interface directly.
Systems can export the XFN interface. Naming systems, such as DNS and X.500, and naming systems embedded in other services, like the file system and printing service, in combination with XFN, are examples of naming systems that export the XFN interface.

This book addresses the needs of applications that use the XFN interface. Some examples of these applications are given in the next chapter.

Application Interaction with XFN

The way that client applications interact with XFN to access different naming systems is illustrated in a series of figures.Figure 1-8 shows an application that uses the XFN API and library.

Figure 1-8 Client Application Interaction With XFN

Figure 1-9 shows the details beneath the API. A naming service that is federated is accessed through the XFN client library and a context shared object module. This module translates the XFN calls into naming service-specific calls.

Figure 1-9 Details Beneath XFN API

X.500, DNS, and NIS+ are the naming services that have been federated in the example shown in Figure 1-10.

As resolution of a composite name proceeds, it can cause these different modules to be linked in, depending on the types of contexts referenced in the name.

Figure 1-10 XFN Implementation Examples


1. Introduction to the Federated Naming Service (FNS) API Usage Model


	FNS and Applications Applications that are aware of FNS can expect the namespace to be arranged according to the FNS policies, and applications that bind names in the FNS namespace are expected to follow these policies. Applications use FNS in the following ways: Applications can use FNS through existing interfaces. A significant proportion of FNS use is through existing application programming interfaces. For example, consider a UNIX application that obtains a file name that it later supplies to the UNIX `open()` function. With FNS support for resolution of file names, the application need not be aware that the strings it deals with are composite names rather than the traditional local path names. Many applications can thereby support the use of composite names without modification. Applications can be direct clients of the XFN interface and policies. Application-level utilities, such as the file system, the printing service, and the desktop tools (calendar manager, file manager) are examples of clients that use the XFN interface directly. Systems can export the XFN interface. Naming systems, such as DNS and X.500, and naming systems embedded in other services, like the file system and printing service, in combination with XFN, are examples of naming systems that export the XFN interface. This book addresses the needs of applications that use the XFN interface. Some examples of these applications are given in the next chapter. Application Interaction with XFN The way that client applications interact with XFN to access different naming systems is illustrated in a series of figures.Figure 1-8 shows an application that uses the XFN API and library. Figure 1-8 Client Application Interaction With XFN Figure 1-9 shows the details beneath the API. A naming service that is federated is accessed through the XFN client library and a context shared object module. This module translates the XFN calls into naming service-specific calls. Figure 1-9 Details Beneath XFN API X.500, DNS, and NIS+ are the naming services that have been federated in the example shown in Figure 1-10. As resolution of a composite name proceeds, it can cause these different modules to be linked in, depending on the types of contexts referenced in the name. Figure 1-10 XFN Implementation Examples