Types of alarms

The alarm server supports three types of alarms; clock alarms, session alarms, orphaned alarms and agenda alarms. There are several other categories of alarms, but these are sub-categories of the main types.

Each of the alarm types is discussed in detail in the following sections.

The alarm server can store up to 8 clock alarms which, once set, are independent of the client that set them. Because they are managed solely by the server, they are serviced even if the application that entered them is not running.

Any client can set any of the clock alarms. These are accessible to the end user through the Time application.

Session alarms are handled on behalf of a session with the alarm server, and fulfil the requirements of PIM applications. Each session is able to set only one session alarm; the server notifies the session when it should set its next alarm.

When a session disconnects from the server, its session alarm is cancelled. The session must specifically orphan its alarm to keep it in the pending alarm queue after disconnection—see below for discussion of orphan alarms.

There are two types of session alarms:

• Timed session alarms are those which belong to timed events—events in a PIM application with a defined start and finish time. The alarm notification time is specified as an offset from the event start time, so that when the event time changes, so too does the alarm time.

• Untimed session alarms, or day alarms, are those which belong to untimed events—events which don’t have a specified start/finish time. This type of alarm stores an actual activation time—rather than an offset to an event time.

A session can orphan its session alarm, and thereby relinquish control of it to the alarm server. The alarm is then stored in the server’s orphaned alarm array. It has no session owner, and no session is notified when the alarm is due.

When a session closes its connection to the alarm server, it may choose to orphan its session alarm—thereby allowing the alarm to be serviced after the session closes. An application can regain control of an orphaned alarm by setting an alarm with the same parameters, e.g. time, date, etc.

After orphaning an alarm, a session is allocated enough memory for another session alarm—which it can also orphan. Sessions can orphan as many alarms as memory allows. The server removes all orphaned alarms when the system time is changed or the alarm server is re-started.

Snoozed alarms are those which have been deferred after activation. When any alarm is snoozed, it is also orphaned.

Other alarm categories are:

• next/pending alarms: alarms that activate in the future—irrespective of type.

• awaiting acknowledgement alarms: alarms for which the alarm time has been reached, or which were initially set at some time in the past.

• acknowledged/review alarms: alarms that have been acknowledged—the server maintains these in a review list until it is cleared, or until they are pushed out of the list by new acknowledged alarms. The server clears the review list when the system time is changed or the alarm server is re-started.

• silenced alarms: alarms that are awaiting acknowledgement, in which the sound notification has been cancelled.