The functional requirements presented in the preceding sections ... . Here's where the aren't of not over specifying comes in.

Draw a nice little picture that shows where the data are actually stored. Viz., in the central repository has a copy of all user calendars, with non- private items and not-yet-accepted meetings. Each user has her own copy of the calendar containing all items, including the private ones, but no not-yet- accepted meetings. Hence, when the view commands operate, they are showing information from potentially both the local copy and the central repository. Viz., all local items plus penciled items for each user looking at her own stuff. When viewing another user, everything comes from the central repository.

Mention the requirement for distributed clock synchronization for comparing the times of scheduler and attendee meeting field changes.

2.14.1. Invoking the Calendar Tool from the Operating Environment

There are to separate executable programs named CalendarTool and CalendarToolAdmin. When a user invokes CalendarTool, the system determines if the invoking user is a registered user of the Calendar Tool system. This check is performed by searching for a user record in the Calendar Tool database containing the invoking user's computer ID on the user's host computer. If the system confirms that the user is registed, then the system displays the regular user interface, otherwise it displays the unregistered user interface.

Explain that the system establishes the user's calendar tool ID by matching it against computer user ID. This means, in effect, that in order for a cal tool user to participate in the network functionality of the system, the user must have an account in an operating environment with a user name.

As explained in ..., admin users must login with a password when invoking CalendarToolAdmin.

2.14.2. The Central Calendar Repository

If the item limit value is set such that it is smaller than the current number of items on the user's calendar in the central repository, the system deletes enough items to reach the limit value. Item deletion is performed in the following order, until the limit is reached:

1. items before today's date are deleted, in order from the earliest to latest scheduled time and date
2. if further deletion is required, items are deleted in order from that latest scheduled time and

Points:

• Central system stores all notifications (including host-change messages) until user computers are ready to receive them.
• As soon as user machines are ready to receive them, central machine sends them.
• Implementors can figure how to do this in any combination of distributed implementations.

The central system coordiates the synchronization of meeting schedulers.

2.14.5. Implementation Considerations

An important characteristic of the central caltool host is that it is assumed to stay running all of the time, whereas individual users may turn their computers off or disconnect them from the network. If users aren't allowed to do this, then a distributed implementation is allowed. Here's the deal with this -- whenever a caltool user's computer is running and connected to the network, other users can see the latest public items and receive notifications immeidately from that user. Whether they

OK, maybe we do need to be a bit more restrictive in the model than the "weak view" paragraphs below indicate. Try this. From each user's perspecitive, there's her own computer with her own personal stuff and the Caltool host computer, which is the "gateway" to everyone else's stuff. Now, the implementation freedom comes in in how the gateway computer chooses to store stuff. It can either store central copies or ship out distributed copies. If it does the latter, things might get tricky cause it's not allowed to ever let anyone's copy of the "central" database get out of date or inconsistent. As far as the central calendar is concerned, it could in fact be highly distributed. There does need to be a place wher

The following paragraphs discuss a weak view of the implementation:

The idea of the "central" calendar need not be implemented on a single central server, it need only appear that way to users. Viz., from a single user's perspective, the user owns a local file that is her personal calendar. Everyone else's calendar is "out there", accessible when asked for, assuming the computer holding the desired information is running.

The central host computer is where the database information is stored. It may or may not be where a central calendar is stored.

Need to allow the case where central calendar contains references to local calendars, as long as proper semantics are maintained.