Complete Contents
Preface
Chapter 1 Overview of Architecture
Chapter 2 Web Calendar Access Protocol (WCAP)
Chapter 3 Calendar Server API (CSAPI)
Index
iPlanet Calendar Server: Programmer's Reference: Overview of Architecture
Previous Next Contents Index


Chapter 1 Overview of Architecture

The iPlanet Calendar Server is designed for programmers who want a full web calendar solution. It is a general purpose server to support applications that need calendar data.


Core Architecture
The calendar server uses HTTP as its primary transport. It receives commands encoded in HTML and sends replies as HTML and JavaScript. The data returned from requests is not formatted for display. The embedded JavaScript generates HTML which it sends to a visible frame. The user experience is the same as if the HTML was loaded from a server. The advantage is that for many operations, the JavaScript can handle everything locally and does not need to contact the server. This provides a faster screen update for the user while lightening the load on the server.

Figure 1.1 shows the core architecture of Calendar Server. The subsystems and data flow are discussed in more detail in the sections that follow.

Figure 1.1    Calendar Server Core Architecture

 HyperText Transfer Protocol (HTTP)
Commands enter through the Protocols module. This module is a minimal HTTP implementation, streamlined to support calendar requests. The requests are in Web Calendar Access Protocol (WCAP), a simple protocol for storing, retrieving, and administering calendars. The WCAP protocol is described in Chapter 2, Web Calendar Access Protocol (WCAP).

Web Calendar Access Protocol (WCAP)
The WCAP subsystem interprets a command and sends it to the Core subsystem for execution. The Core system makes data requests to the Caldb subsystem where information is stored or retrieved from the database as needed and returned in a low-level format. The Core subsystem then translates the low-level format into the format requested in the WCAP command. These results are then encoded in HTML and returned.

Calendar Server Application Program Interface (CSAPI)
CSAPI is an API you can use to add functionality to Calendar Server or to augment the way certain operations in the server are performed. You can use CSAPI to modify the following major areas of functionality:

For example, the server's default mechanism for authentication uses LDAP, and user preferences are stored in LDAP by default. You may have an existing infrastructure for authenticating users and saving user preferences which is not based on LDAP. You can use CSAPI to override the default mechanisms and use your existing authentication and directory services.

The CSAPI is described in Chapter 3, Calendar Server API (CSAPI).

Supported Format Encoding
For data being stored, the Core translates the input into the binary form that Caldb uses. Calendar Server supports the following format encodings:

You can add other formats by developing a translator DLL or shared library using CSAPI, an API for extending the calendar server.

Calendar Database
By default, Calendar Server uses BerkeleyDB as its database. This database product is provided with the distribution. With Berkeley DB, Calendar Server supports transactions and live backups, as well as a limited form of high-availability.

Calendar Data Format
The calendar data format is modeled after the IETF iCal standard [RFC-2445]. The datastore maintains calendars, which are collections of iCal components. The components include events, to-dos, journal entries, and alarms. A calendar can be owned by one or more users. User attributes are maintained by an external mechanism. By default, that mechanism is LDAP. You can use CSAPI to override the default mechanism.

Calendars have calendar sets, which allow multiple calendar sources to be aggregated into a single calendar for display purposes. A user can, for example, have a default calendar view made up of his or her own calendar, the group's calendar, the holidays calendar, and the "latest action video releases" calendar, which is called a "calendar set".

Calendars also use links. Links are similar to calendar sets, but allow a more granular selection of events to overlay. For example, suppose that a convention center maintains a calendar of all the conventions to be held in its facilities. A user may be interested in one of the conventions, but not in all of them. In this case, the user can add an event into a personal calendar as a link to the event of interest in the convention calendar. Any change to the event in the convention center's calendar will be reflected in the linked copy.

This infrastructure makes it possible to feed real-time event data into the database using import formats such as iCal or XML. Event data can be fed in from calendars such as the San Francisco 49ers season schedule, convention center schedules, concert schedules, or any schedule of events that may be of interest.

Calendar Server provides tools for retrieving calendar data from event feeds and from the database, so that users can view and retrieve event information. The user can link or layer these events onto their own calendar views, providing rich event information that is maintained by third parties.

Calendar Data Exchange
All calendars and events can be referenced as URLs. Users can embed these links in email messages and web pages. Users can click on a link to see a monthly calendar view, a weekly view, a daily view, or a specific event. If the calendars are publicly readable, users will not be asked to log in.

Calendar Server supports server-side email alarms, which can be sent to a list of recipients. The format of the email message is completely configurable. It is currently maintained as a server attribute, rather than as a user or calendar attribute.

Currently, Calendar Server has limited support for the ITIP/IMIP standards [RFC-2446, RFC-2447]. A user can send out IMIP PUBLISH messages, and the server can import the text or calendar portion of an IMIP PUBLISH message.


User Data
The primary component of user data is the calendar set, or list of calendars that belong to a user. A user's calendar data is associated with the user through a calendar set user preference, which lists all the calendars that make up that user's calendar set.

Calendar User Preferences
Calendar Server customizes the display of calendaring information for each user according to attributes called user preferences. User preferences, as opposed to calendar preferences, refer to the user interface representation of information. User preferences include such things as email address, user name, and preferred colors to use when rendering calendar information. For a complete list of preferences, see the get_calprops and set_calprops command descriptions in Chapter 2, Web Calendar Access Protocol (WCAP).

Calendar Access Control
A calendar can have multiple owners, but it has only one primary owner. You can control access to a calendar by specifying its read access or write access as either public or private.

When a calendar is public, anyone has access for that type of action on the calendar, including an anonymous user.

When a calendar is private, access is limited to the owners.

To issue commands for a calendar that is marked as private, you must provide the session identifier that was returned by the login command for your session. Because your identity is authenticated at login, the identifier protects the private data from being read or written to by unauthorized users. For more information on session identifiers and authentication, see the following sections:

 

© Copyright 1999 Sun Microsystems, Inc. Some preexisting portions Copyright © Netscape Communications Corp. All rights reserved.