As outlined in the UI Overview, the Calendar Tool system is comprised of two separate application programs. The regular user program runs on as many client computers as there are users. It provides functionality to view and modify calendars, and connect to a central server on which shared user calendars are stored. The other application program is for privileged administrators to maintain the databases on the central server.

In the regular user application, the major object in the user program is the Calendar. It's implementation will need to provide efficient access for a wide range of operations, including serial navigation, lookup by date, and filtered searching. Hence, it will need to use a moderately sophisticated data structure that supports these various forms of access. For example, it could use a hashed top-level index, with threading among hash table entries to support serial traversal.

Aside for the Calendar, the other objects in the regular user calendar tool should have reasonably straightforward implementations. The different forms of calendar viewing will produce dynamic objects, that need not be exists in persistent storage. Rather, the views are computed form the underlying calendar data, displayed on user demand, and then discarded. The Calendar data structur will need to provide access functions to support the different views.

In administrative application, the major objects are the three databases for Users, Groups, and Locations. The projected size of these databases is probably not big enough to require implementation using a database management system. Rather, some form of efficiently searchable collection should do. The reason this is the case is that there are requirements for sophisticated querying against the databases, and query support is typically the most important reason to employ database management technology.

The distributed processing of the networked Calendar Tool environment will require specific development expertise. In particular, the developers need knowledge of client/server design and implementation. Functionality to support client/server architectures is available in many modern libraries. It will make sense for the developers to choose an implementation language in which client/server support is available, dependable, and well documented.