Overview

Your task is to develop a calendar system that will allow a community of users to schedule events and allocate resources. The application contains the following entities:

Users. Each user has a name, password, email, and other attributes.
Groups. Each group is a set of users. Groups can be overlapping, for example there could be a group of chess-players and a group of stamp-collectors that overlap. Groups can also be hierarchical, e.g. the group hobbyist consists of all chess-players and stamp-collectors. Users should be able to create new groups.
Events. An event is the basic unit of data in the calendar system. It consists of start date and time, end date and time, description, owner (a user), a list of attendees (users and/or groups), resource allocations and/or de-allocations, actions, and other attributes.
Resources. These can be rooms, A/V equipment, or other resources. Resources can be allocated or de-allocated during events, e.g. rooms can reserved or released, overhead projectors can be leased or returned. A resource can be allocated at the beginning of the event and de-allocated at the end, or it can be allocated during one event and de-allocated during another.
Actions. These can be of several types. At a minimum your project has to include email actions. Other possibilities are: printing a message, popping-up a window, dialing a telephone number.

Events will always be scheduled by a single user (the owner of the event) but may apply to a set of users or groups. You will act as administrator of the calendar system, and will establish a set of users and resources to begin with. Events may conflict either because they overlap in time or because they require a resource that is unavailable at that time. You should allow users to schedule conflicting events, but may assist them in finding or removing conflicts.

Access Modes

Your system should allow users to perform operations on events (view, schedule, modify, and delete events), manage group membership, and browse the data in the calendar in various ways. The system will be accessed in two modes: through a Web interface or via email.

Web Interface. All operations are performed here through the Web browser. A WEEK VIEW page is required, which, for a given user or group and a specified week, returns all relevant results in table form, as in this sample. Other views or pages will not be explicitly required, but are left for you to design. You are likely to need an EVENT VIEW and a USER VIEW. Updates to the calendar database (scheduling, modifying, or deleting events) should be done through web forms. There are many useful queries that might be incorporated into your interfaces, in the appropriate context. Here are some examples:

What rooms are available on Friday from 1pm – 2pm ?
Are there any conflicts in my scheduled events ?
What is the next hour-long time period which is available to all members of the database group ?
How many database group members are free to attend a meeting next Tuesday from 2:30 to 3:30 ?
To what groups do I belong ?

You should be creative in identifying additional useful queries, and making them accessible to the user through the web. This may be through form-based pages, but in some cases, a link in the right place which returns query results will suffice. Obviously, we don't expect the user to submit SQL queries to extract information, so assisted interfaces are required. Also, you will need to authenticate the user before allowing access through the Web interface.

Email interface. Some operations can be performed via email, with results also returned by email. At a minimum you should implement the WEEK VIEW operation, but you are encouraged to implement other operations too. The emails’ bodies contain XML data. You need to define your own XML protocol for encoding requests for operations and returning results. For example a request for viewing the calendar events for user John with some additional conditions could be:

<viewCalendar>

<userName> John </userName>

<peridod> <startDay> 255 </startDay>

<endDay> 262 </endDay>

</period>

<conditions> <attendee> Smith </attendee>

<attendee> Brian </attendee>

<room> GWN 201 </room>

</conditions>

</viewCalendar>

This requests all events for the user John, between the days 255 and 262 (of the calendar year) that also include Smith and Brian and that request the room GWN 201. The reply may be:

<events>

<event>

<day> 257 </day>

<period> <begin> 10am </begin> <end> 11am </end> </period>

<description> Our weekly meeting </description>

<attendee> John </attendee>

<attendee> Smith </attendee>

<attendee> Mary </attendee>

<attendee> Brian </attendee>

<resource> <type> room </type> <name> GWN 201 </name> </resource>

<resource> <type> projector </type> <name> LargeOHP </name> </resource>

</event>

</event> … </event>

…

</events>

Do not worry about user-friendliness: these XML messages are supposed to be created and interpreted by programs, so they need to be application-friendly. Your program needs to interpret the request (the first XML message) but does not need to interpret the reply (the assumption is that some application would read the email's body and interpret it, but you don't need to write that application). Your program needs to create the reply (in response to the request) but it does not need to create the request: you will create it manually and send it by email. You do not need to address security for email access. Also, you are not expected to write an XML parser, because many are already available (see the support page).

Security

Your calendar implementation must include a reasonable security policy using password authentication for all web-based access. For instance, a user should have access only to calendar events that apply to him, in the sense that the user owns the event, or is a member of a group to which the event applies. We will assume however that all members of the calendar community are willing to export a limited view of their scheduled events which says only that the user is occupied or not occupied at a given time but does not allow others to see the location or purpose of the events.

Systems Resources [Support Page]

This project will require you to use a variety of tools. We have provided a collection of recommended tools and systems for which we will provide some assistance and support. You may choose to diverge from our recommendations at your own risk. If your implementation works, and it constitutes original work, then it should be fine. Your data will be stored in a PostgreSQL database system running on cubist. (PostgreSQL is an open-source database management system which is a popular choice for Linux). Your dynamic web-pages will be constructed using Perl, PHP, C/C++ or a combination thereof. The support page linked above contains sample code and tutorials that should serve as a starting point.

Project Milestones:

Milestone 1 - Oct. 15 Form groups of 3 or 4, choose a team name, and notify your TA by email of each member’s name and username.

Milestone 2 - Oct. 22 Design an E/R diagram for the calendar application. Create the corresponding schema in PostgreSQL, and add some sample data. Using Perl or PHP or the tool of your choice, design a rudimentary web page which connects to your database and extracts some data. The support page will be helpful for this. Submit your E/R diagram in writing, and send your TA a link to the trial Web page.

Milestone 3 - Oct. 29 Design the WEEK VIEW web interface. It need not be complete; you can fine-tune it later. Submit, by email, a link to your working WEEK VIEW page. You may ignore authentication and assume a default user.

Nov. 5: MIDTERM

Milestone 4 - Nov. 14: Improve WEEK VIEW and complete the Web-based access methods including interfaces for insertion/modification of events, and other more advanced queries. Design the operations you will support through the email access interface. For each operation, design a DTD for the request of that operation and a DTD for the reply. Submit a link to your working system and the DTD's in writing.

Milestone 5 - Nov. 19: Add user authentication. Create a rudimentary email access method by implementing the view calendar operation. Submit a link to your working system.

Milestone 6 - Nov. 26: Complete the email interface. Your system should interpret operations received by email, and respond appropriately.

Dec. 3-7: Project demos