Functional Architecture

This section describes the functional architecture of services supporting the CSA API. It provides an abstract implementation model, an abstract data model, and a functional overview.

Implementation Model

The abstract implementation model is provided as a reference aid to help you understand the scope of the CSA API.

The CSA interface is defined between a calendar-enabled application and a calendaring service. All functions in this interface are designed to be independent of the calendaring service; however, the API does allow protocol-specific extensions to the common functions to be invoked through the use of extensions. See "Extensions" for more information. The relationship of the CSA interface to a calendar-enabled application and the calendar service is shown in Figure 10-1.

Figure 10-1 Positioning of the Calendaring and Scheduling API

The model of the CSA interface can be divided into three components: administration, calendar management, and entry management. These components are shown in Figure 10-2.

Figure 10-2 Components of the Calendaring and Scheduling API

Access to the calendaring service is established through a calendaring session. The session provides for a valid connection to the calendaring service and assists in ensuring the integrity of the calendaring information maintained by the service. A calendar-enabled application logs on to an individual calendar within the calendaring service to establish a valid session or connection. The session is terminated by the calendar-enabled application logging off from the calendar.

The calendaring service maintains one or more calendars. The calendar service provides some level of administration support for these calendars. A calendar-enabled application might access a list of the calendars maintained by a particular calendar service. In addition, the calendar service might provide support for archive and restore of calendar information into some implementation-specific, persistent format. Where a calendar service provides support for maintaining more than one calendar, support functions are defined for creating and deleting calendars. In addition, functions are provided to support administering the characteristics of the calendar.

The majority of the functions within the CSA interface manage individual calendar entries. Calendar entries may be either events, to dos, or memos. Entries can be added, deleted, updated, and read from a particular calendar. A calendar-enabled application can also add reminders to calendar entries.

Data Model

The CSA interface is an access method to a conceptual back-end store of calendaring information that is maintained by a calendaring service. A common data model is helpful in visualizing the components of the calendaring information maintained by a calendaring service.

Calendar Entities

The data model is based on the concept of a calendar entity. The calendar is represented by a named collection of administrative calendar attributes and calendar entries. A calendar is owned by an individual user. The user could represent a person, a group of people, or a resource.

The calendar attributes are a set of named values that may represent common, implementation-specific, or application-specific administrative characteristics about the calendar. For example, time zone, name, owner, and access rights to the calendar can be specified in individual calendar attributes.

The calendar entries are the primary components of a calendar. The three classes of calendar entries follow:

• Events

• To Dos

• Memos

Calendar entries are represented by a uniquely named collection of entry attributes. The entry attributes are a set of named values that represent common, implementation-specific, or application-specific characteristics of the calendar entry. For example, an event might contain a start and end date and time, a description, and a subtype. A to do might contain the date it was created, the due date, a priority, and a status. A memo might contain the date it was created and a text content or description.

The calendar attributes and entry attributes consist of a name, type, and value tuple. Common attributes defined by the specification can be extended. Implementations can define implementation-specific attributes. In addition, some implementations may provide the capability for applications to define application-specific attributes. The CDE implementation supports application-defined attributes.

Access Rights

The accessibility of a calendar to an individual user can be controlled by the access rights given that user. Access rights are paired with a calendar user. CSA allows a user to be an individual, group, or resource. The CDE implementation only supports individual users. The access rights are maintained in an access list. The access list is a particular calendar attribute. The access rights are individually controlled and can be accumulated to define a range of accessibility of a user to a calendar and its entries. The access rights can also be specified in terms of the following access roles:

• The owner of a calendar

• The organizer of a particular entry within the calendar

• The sponsor of a particular entry within the calendar

The owner role enables the user to do anything to the calendar or calendar entries that the owner of the calendar can do, including deleting the calendar; viewing, inserting, and changing calendar attributes; adding and deleting calendar entries; and viewing, inserting, and changing entry attributes.

The organizer role enables the user to delete the entry or view and change entry attributes of those calendar entries for which the user is specified as the organizer. The organizer defaults to the calendar user who created the entry.

The sponsor role enables the user to delete the entry or view and change entry attributes for those calendar entries for which the user is specified as the sponsor. The sponsor is the calendar user who effectively owns the calendar entry.

In addition to these roles, an access right can be set to limit access to free time searches; view, insert, or change calendar attributes; or view, insert or change entries, depending on whether they are classified as public, confidential, or private. The entry classification acts as a secondary filter on accessibility.

Functional Overview

The CSA interface supports three principle types of tasks:

• Administration

• Calendar management

• Entry management

Administration

Most of the CSA function calls occur within a calendar session. The calendar session is a logical connection between the calendar-enabled application and a particular calendar maintained by the calendaring service. A session is established with a call to the csa_logon() function and terminated with a call to the csa_logoff() function. The context of the session is represented by a session handle. This handle provides a token in each of the CSA functions to distinguish one calendar session from another. The csa_logon() function also authenticates the user to the calendaring service and sets session attributes. Currently, there is no support for sharing calendar sessions among applications.

The csa_list_calendars() function is used to list the names of the calendars managed by a particular calendar service.

The csa_query_configuration() function is used to list information about the current calendar service configuration. This information can include the character set, line terminator characters for text strings, default service name, default authorization user identifier for the specified calendar service, an indicator of whether a password is needed to authenticate the user identifier, an indicator of whether the common extensions for user interface dialogs is supported, and the CSA specification supported by the implementation.

The CSA implementation provides support for managing the memory for calendar objects and attributes that are returned by the service. The csa_free() function is used to free up this memory after it is no longer needed. It is the responsibility of the application to free up the memory allocated and managed by the calendar service.

Calendar Management

The CSA interface provides several calendar management functions. The CDE implementation supports multiple calendars per calendar service; the calendar-enabled application can add or delete calendars. The csa_delete_calendar() function is used to delete calendars. The csa_add_calendar() function is used to add new calendars to the service.

The application can also list, read, and update calendar attributes using the csa_list_calendar_attributes(), csa_read_calendar_attributes(), and csa_update_calendar_attributes() functions. The application can register callback functions for receiving notification of a calendar logon, calendar deletion, update of calendar attributes, addition of a new calendar entry, deletion of a calendar entry, and update of a calendar entry. The callback function is only registered for the duration of the calendar session. In any case, this information may be invaluable for some calendar administration applications.

Entry Management

The CSA interface has a robust set of functions for managing calendar entries. The context of a calendar entry in a calendar session is maintained by the entry handle. This handle provides a token in the CSA functions to distinguish one calendar entry from another. The entry handle is returned by the csa_add_entry() and csa_list_entries() functions. The entry handle is valid for the duration of the calendar session or until the entry is deleted or updated. The entry handle becomes invalid when it is freed by a call to csa_free().

The csa_add_entry() function is used to add new entries to a calendar. The csa_delete_entry() function is used to delete an entry in a calendar. The csa_list_entries() function is used to enumerate the calendar entries that match a particular set of entry attribute criteria. The csa_read_entry_attributes() function is used to get either all or a set of entry attribute values associated with a particular calendar entry.

To add an entry to a calendar, a calendar-enabled application must first establish a session with the calendaring service using the csa_logon() function. Then the application invokes the csa_add_entry() function to specify the new entry. The calendar-enabled application is responsible for composing the attributes used in the csa_add_entry() function. The session is terminated using the csa_logoff() function.

The entry attributes in an individual calendar entry can be enumerated with the csa_list_entry_attributes() function. The values of one or more attributes can be read with the csa_read_entry_attributes() function. Individual entry attributes can be modified with the csa_update_entry_attributes() function.

Memory allocated by the CSA implementation for retrieved calendar information is released by passing the associated memory pointers to the csa_free() function.

Some calendar entries are associated with a recurring activity. The csa_list_entry_sequence() function can be used to enumerate the other recurring calendar entries. This function returns a list of entry handles for the recurring entries.

The CDE calendar server provides support for alarms or reminders to be associated with calendar entries. Reminders can take the form of audio reminders from the terminal speaker, flashing reminders presented on the terminal screen, mail reminders sent to the calendar user, or pop-up reminders presented on the terminal screen. The calendar service manages the reminders, but it is the responsibility of the calendar application to retrieve the reminder information and act on it. The csa_read_next_reminder() function is used to read the information about the next scheduled type of reminder.

Extensions

The major data structures and functions defined in the CSA specification can be extended methodically through extensions. Extensions are used to add additional fields to data structures and additional parameters to a function call. A standard generic data structure has been defined for these extensions. It consists of an item code, identifying the extension; an item data, holding the length of extension data or the data itself; an item reference, pointing to where the extension value is stored or NULL if there is no related item storage; and flags for the extension.

Extensions that are additional parameters to a function call may be input or output. That is, the extension may be passed as input parameters from the application to the CSA service or passed as output parameters from CSA service to the application. If an extension is an input parameter, the application allocates memory for the extension structure and any other structures associated with the extension. If an extension is an output parameter, the CSA service allocates the storage for the extension result, if necessary. In this case, the application must free the allocated storage with a csa_free() call.

If an extension that is not supported is requested, CSA_E_UNSUPPORTED_FUNCTION_EXT is returned.

About the CDE Implementation

The CDE implementation of the CSA API consists of a library which provides access to the CDE calendar server. ONC RPC is used for communication between the library and the server. The calendar server in the CDE implementation is a version 5 server which supports calendar protocol versions 2 to 5 and data versions 3 and 4. Calendar protocol versions 2 to 4 and data version 3 are for backward compatibility to OpenWindows Calendar Manager. Calendar protocol version 5 and data version 4 support the CSA interface and data extensibility.

Table 10-2 Server Version/Data Version Supported

Server Version	Data Version Supported
2	1
3	2
4	3
5	3, 4

Access models supported

Two access models are supported by the calendar API. The access model specified in the XAPIA CSA specification is supported for data version 4 only. The OpenWindows Calendar Manager access model is supported for data versions 1 to 3. In the OpenWindows Calendar Manager access model, the accessibility of a calendar is controlled by an access list which specifies who has what access rights. Three access rights are defined: CSA_X_DT_BROWSE_ACCESS (user can list and read calendar entries), CSA_X_DT_INSERT_ACCESS (user can insert calendar entries), and CSA_X_DT_DELETE_ACCESS (user can delete calendar entries). Since the calendar API allows access to calendars of all versions, the programmer should interpret the access rights contained in an access list using the correct access model depending on the data version.

When a calendar is created, unless an access list is specified during creation, the default access list consists of one entry with "world" as the user name; the associated access right is "browse public entries." The user name "world" is a special name which means all users.

By default, a user with the same user name as the owner of the calendar can access the calendar with full owner's access from any machine. To have stricter access control, names of the form "owner-user-name@host" can be added to the access list of the calendar. When such an entry is added to the access list, the corresponding access right has to be CSA_OWNER_RIGHTS for data version 4 and (CSA_X_DT_BROWSE_ACCESS|CSA_X_DT_INSERT_ACCESS|CSA_X_DT_DELETE_ACCESS) for data version 3. After such entries are added to the access list, only users from the specified hosts can access the calendar with full owner's rights.