Yet another attempt to devise a workable Web based calendar of events having certain constraints:
- Multiple managers: all staff and faculty can add and remove items
- Multiple calendars: events and schedules for many different things
- Simple enough for someone unfamilair with the system to operate successfully
- Secure enough to prevent routine cracking by students
- Reasonably easy to administer
- Reasonable demands on the Web server
- Capability for restricted read access
This approach abandons the wall calendar model and uses the day planner model instead: entries simply follow each other under month, day, and time headings.
Entry management is via e-mail:
- The message subject is the calendar name
- The entry body follows the first blank line in the message
- The first line is the date and/or time under which it is to be listed
- If a second line precedes the first blank line, it is the ending date/time, or a notation such as "all day", "for two hours", etc.
- The body can be any text followed by a blank line
- .sigs must be allowed, but not required, and must be stripped off if present: the last paragraph will be removed if there are more than two blank lines
- Deletion messages have DELETE (case insensitive) as the subject, and the calendar name followed by the entry ID (the base part of the file's name) as the first line in the body (the rest of the body will be ignored)
The overall structure is based on an e-mail client to filter messages for security and to pass each incoming message to an application program which will process it, and on a CGI process based on the DIRLIST code to generate the pages to be displayed to the users.
- Each entry in a claendar is a separate file
- Each calendar is a separate directory - placing the directory on the LAN and returning a file:/// type URL (instead of a page) allows control of who can read the calendar
- The CGI process deletes out of date files as it prepares the response page
- Each entry file has a filename of the form YYYYMMDDhhmmnn.txt and is a plaintext file (nn represents a sequence number to deal with duplicate entries for the same date/time)
There are two mail processing applications
- ADDENTRY, which receives messages that
- Pass the security check by having From: fields that intersect the valid names in the nicknames list (note that this is global)
- Do not contain "Delete" (in any case) as the subject
- REMOVEENTRY, which receives messages that
- Pass the security check
- Do have "Delete" as the subject
These programs can contain any additional security features needed or wanted.
The plan also calls for two CGI programs
- GETCALENDAR, which processed requests for public calendars - this program performs no security checking
- GETSECURECALENDAR, which processes requests for secure calendars - this program would be a bit complicated since it would have to manage tansient files used for its responses (I hope I don't have to write this one)