This is a description of how one application, a calendar service, could be modified to use FNS policies. This example illustrates how FNS composite names might be presented to and accepted from users.
The DeskSet's calendar service is typical of client-server applications. Calendar servers run on some set of machines and maintain the users' calendars. Calendar Manager (cm) runs on the desktop and contacts the appropriate server to obtain the calendars of interest.
The calendar service could benefit from FNS using a simple registry/lookup model as follows:
Binding - Upon startup, the server registers the calendars that it manages by binding a reference containing its own ONC+ RPC address (host, program, version) to the composite name for each calendar it manages, such as user/jsmith/service/calendar.
Lookup - When using cm, the user specifies another user's calendar simply by entering the user's name (for example, hirokani) or selecting it from a list of names previously entered. Given the user name hirokani, cm composes the composite name user/hirokani/service/calendar and uses this to look up the RPC address that it needs to communicate with the server that manages that calendar.
In the previous example, we used the name "calendar" to denote a calendar binding. The developers of the calendar service should register the name "calendar" with the FNS administrator, much as RPC programs are registered with the RPC administrator. Refer to "Service Name and Reference Registration".
The name "calendar" used here is an example. FNS policy does not specify the names of specific services.
The calendar service could take further advantage of FNS policy by allowing calendars to be associated with sites, organizations, and hosts, while still naming them in a uniform way. For example, by allowing calendars to be associated with a conference room (a site), the service can be used to "multibrowse" the conference room's calendar as well as a set of user calendars to find an available time for a meeting in that room. Similarly, calendars can be associated with organizations for group meetings and hosts for keeping maintenance schedules.
The cm calendar manager could simplify what the user needs to specify by following some simple steps.
cm uses a tool for accepting composite names from the user and constructing the name of the object whose calendar is of interest.
The object is the name of a user, a site, a host, or an organization. For example, the user might enter the name kuanda and the calendar manager generates the composite name user/kuanda. This tool could be shared among a group of DeskSet applications.
cm uses the XFN interface to compose this name with the suffix /service/calendar to obtain the name of the calendar.
This calendar name is then resolved relative to the process's initial context.
Continuing with the example, this results in the resolution of the name user/kuanda/service/calendar. Similarly, if the user enters the name of a site, pine.bldg-5, cm generates the name site/pine.bldg-5/service/calendar for resolution.
Other services such as printing and mail could take advantage of the FNS policies in a similar way.