CSE 444 - Autumn 2001

Project Description:       Community Calendar Program



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:


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:


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:



     <userName> John </userName>

     <peridod> <startDay> 255 </startDay>

               <endDay> 262 </endDay>


     <conditions> <attendee> Smith </attendee>

                  <attendee> Brian </attendee>

                  <room> GWN 201 </room>




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:




        <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>




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). 



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