UW Calendar logoWelcome to the University of Washington's
UW Calendar Project

Overview

Using UW Calendar

Download

Get Involved

Additional Resources

August 2006 - Current status of UW Calendar and this website:

The UW Calendar project has evolved into Bedework. Please see the Bedework website for current code and updates. We will continue to keep this website up as an archive of the status of UW Calendar as of August 2006.

What is UW Calendar?

The UW Calendar project is building an open-source calendaring system for higher education. UW Calendar will support personal, public and group events, use existing open standards, and support web-based and other forms of access, including uPortal integration.

Who Uses UW Calendar?

UW Calendar in production:

UW Calendar in development:


News
  • August 2006
    • Bedework 3.1, the successor to UW Calendar, has been released. Please see the Bedework website for current code and updates.
  • August 2005
    • A new Frequently Asked Questions document (largely written by Gary Schwartz, Mike Douglass, and Arlen Johnson of RPI) has been added to the website. The master copy will be kept in CVS under the docs directory. Another fairly up-to-date version will be available on the RPI CCT website
  • July 2005
    • UW Calendar version 2.3.2 is now available. This release contains partial support of the evolving CalDAV server standard, more JSR 168 (portlet) support, and a number of other bugfixes and improvements. [Note: 2.3.2 fixes a minor bug in three files in 2.3.1. The calendar application itself has not changed.]

      See the download page for more information.

      quickstart | calendar application only | release notes

  • June 2005
    • UW Calendar version 2.3.1 is now available. [Note: 2.3.1 fixes a minor bug in the configuration files discovered just a few days after version 2.3 was released].

  • News Archive
The Problem

People affiliated with a college or university typically must keep track of a multitude of calendars. Consider Joan, a graduate student at a university. Joan is taking three classes and working with a research group. To keep track of all the events in her day, Joan must follow the university's academic calendar, her department's calendar (for colloquia and seminars), a calendar for each of her three classes, the calendar for her research group, and her private calendar (for dental check-ups, etc.). If she has any outside interests, such as playing on an intramural sports team, each of these will have its own calendar. Finally, there are likely to be many other events Joan might be interested in attending, but never hears about. Clearly, Joan's life would be easier if all these calendars were available in a single system.

Each person at a college or university will have different calendaring needs. A staff member, for example, will be more dependent on group calendaring, a freshman probably less so. Some staff and faculty will need to schedule events with people outside the institution, and might need to have some of their scheduling done by an assistant. But all users would benefit from an institution-wide system that allows users to view and manage their public, private and group events in one place.

An institution, department, or individual may already have partially solved their calendaring problem, so any new calendaring system must be modular and work with other systems. For example, all institutions keep events such as class schedules in a central system already, and it would be unwise to duplicate these events in another system. Other current partial solutions might include a commercial group calendaring system, a department's set of web pages for colloquia, or a person's handheld computer. A large part of the calendaring problem is integrating as many of these systems as possible.

The Solution

UW Calendar will consist of many components (see the System Architecture diagram). We can classify these components as follows:

  1. A server (also sometimes called a calendar store or calendar service). The server holds events and other similar objects. UW Calendar will include its own standalone server running using a relational database. In addition, there may already be stores of events on campus which, using open standards, can be made to work with the UW Calendar system. Thus, conceptually there may be multiple servers in the system.
  2. An aggregator. This component takes the output of multiple servers and combines them into what seems like a single source of data. For example, to construct a student's calendar for today, the aggregator might get data from the class schedule database and a separate database of personal events. Applications that only deal with data from one source, of course, need not use an aggragator.
  3. The Big Four applications:
    • A personal calendar application
    • A public events entry application. This would typically only be usable by a subset of people, particularly if only "official" public events can be stored on the server.
    • A public events display application. This would typically be usable by anyone, including members of the general public, to view events at the institution.
    • A group calendaring application.
  4. Numerous smaller applications and widgets. For example:
    • A version of a person's calendar suitable for inclusion in a portal channel.
    • Tools to create a web page corresponding to a subset of public events (e.g., Upcoming English department colloquia)
    • An 'add this event to my calendar' tool, suitable for use via clicking on an icon next to a public event displayed on the web.
    • Similarly, 'add my class schedule' or 'add my finals schedule' tools
    • Similarly, a tool to 'subscribe' a user to events of a particular kind, such as author readings sponsored by the bookstore. Note that this would include events that haven't been added yet as well as those that currently exist.
    • Tools to sync a person's calendar with a copy on another system, such as a handheld device.

Some of the above components might overlap with each other, or even be combined into a single tool. For example, the 'add this event to my calendar' widget would almost certainly appear in the public events display application, while group calendaring might be folded into the personal calendaring application.

For a complete list of features planned for UW Calendar, see the requirements document.

Features

UW Calendar is based on UW Calendar, a University of Washington system with the following features:

  1. A database for storing general events, with a schema derived from the iCalendar standard (iCal). For a detailed description of this standard, see RFC 2445.
  2. Code to convert UW Calendar events to iCal (and vice versa).
  3. A web-based personal calendaring application.
  4. A public events entry system.
  5. A public events display system.
  6. Integration of public and private calendars.
  7. A service to generate a peephole view of a person's calendar, suitable for display in MyUW, the University of Washington's portal. (Note that MyUW is not based on uPortal).

UW Calendar is written in Java. The current code download contains items 1-6.

Legal Notices

The University of Washington licenses the source code of UW Calendar under a "BSD-style" open source license. This license permits use of the source code by anyone for any purpose, including commercial purposes, requiring only that acknowledgment be given. As the package evolves and other institutions and individuals contribute to the package, license terms for package parts and for the package as a whole will be an issue about which the project participants must achieve consensus. The University of Washington is, however, committed to preserving these license terms for its contributions, and we will work to insure that the BSD-style license terms will continue to be used for this package indefinitely.

Authors of significant contributions to the UW Calendar project must have a signed copy of the Contributor License Agreement on file at the University of Washington. This document assigns the University of Washington a copyright license on your contributions to the project. All authors still retain their copyrights. This agreement serves at least two purposes. First, it provides clear proof that the contributions can be distributed as part of the UW Calendar project. Second, should someone decide to take some sort of legal action against the project, the University of Washington could step forward immediately as the party defending UW Calendar, instead of having to track down all the authors.

Vision Statement

UW Calendar will be a total calendaring and events system for institutions of higher learning. It will store and retrieve private events, official and unofficial public events, and group events, as well as schedules for resources such as rooms, equipment, and computer time. It will include applications to view and edit any useful calendar that can be derived from these events, including calendars oriented to a single person, a single resource, a group of people, or a large entity such as a department. It will include applications to facilitate group scheduling, including groups whose members span institutions using different instances of UW Calendar.

UW Calendar will be open source and platform independent. It will use existing open standards where possible, especially the standards of the IETF Calendaring and Scheduling Working Group. It will support integration with other systems and middleware, particularly open systems such as uPortal and Shibboleth. It will be modular, so an institution can deploy only the components it needs, and extensible, so an institution can build any new component it needs.


University of Washington
Computing & Communications
calendar_users@u.washington.edu