View this PageEdit this PageUploads to this PageVersions of this PageHomeRecent ChangesSearchHelp Guide

Aggregated Calendars

Class Project:
Combined-Calendars (iCal format)

Participants: Adam Franco, Ramprasad Mantravadi

I (Adam) have been playing around a bit recently with iCal-format calendars and have run into problems when trying to manage the viewing of many (10s of) calendars and am pondering better ways to manage, sort, and browse events from many (online or offline) calendars. One useful possibility would be to make a combined calendar which would be the union of events from a set of calendars.

A server could be made which would periodically poll a set of calendars (either remote URLs or local files) and then build a calendar out of the union of events from the set. This combined calendar could then be subscribed to by clients itself. Several groups have done calendaring things over the past few years, but I don't believe that any have done anything along the lines of this.

Parts involved:
  • A calendar client which could download and parse iCal calendars.
  • A set maintainer that would manage what calendars belong in what set and merge events from all calendars in a set.
  • A calendar server which could either answer HTTP requests or simply place/upload the resulting calendar to a web-accessible directory.
    • Seaside, http://beta4.com/seaside2/, could be useful for serving calendars.
    • The Monticello package's MCFileBasedRepository provides methods for writing files to local-filesystem/FTP-servers/HTTP-servers/etc. The Repositories could be used directly or used as a template for a general remote-storage system.
  • Interfaces for managing the calendars in a set.
    • A Seaside-based interface with user authentication would allow for the aggegater to be placed on a webserver and accessed remotely.
    • A Morphic-based interface would allow the aggregater to be run as a desktop application.
  • An authentication system to control access to the web-based management interface.

An additional idea is to maintain a database of many calendars and some associated meta-data. Then, in response to a search query dynamically generate a combined calendar that contains all events from calendars matching that query. Alternatively, instead of metadata/searching, a hierarchy could be made.

One of the key things is that the source calendars are not necessarily (or even probably) maintained locally and therefore cannot be aggregated using existing tools, hence the need for a new tool. Some examples of these calendars can be found at:
  • http://icalshare.com/
  • http://www.icalworld.com/
  • http://www.swingcalendars.org (a side project that I am doing that inspired this idea).

Installation Instructions:

  1. Download and open a Squeak 3.7 Image
  2. Open the SqueakMap package browser and install the following packages in order:
    1. DynamicBindings
    2. KomServices
    3. KomHttpServer
    4. Seaside
  3. Seaside will ask you for an admin user/password (remember these)
  4. Start Seaside with the following command:
        WAKom startOn: 8888
    (or use another port of your preference)
  5. Load the iCal-Aggregater package via Monticello
  6. Open the Seaside config utility at: http://localhost:8888/seaside/config and add a new entry point for the CalendarAggregater:
    1. Path: calendaraggregater
    2. Type: Seaside Application
    3. Root Component: SeasideAggregater
  7. Head to http://localhost:8888/seaside/calendaraggregater and enjoy

Use Cases:

City Arts Calendar

Situation

The city of Springfield has the following organizations that each publish their own calendars as an iCal-formatted file on their own websites:
  • Springfield Museum Of Modern Art (SMOMA)
    • Painting, drawing, sculpture.
    • http://www.smoma.example/smoma_calendar.ics
  • McMansion Sculpture Garden (MSG)
    • Sculpture.
    • http://www.msg.example/sculpture_events.ics
  • West Side Musical Players (WSMP)
    • Musical theater.
    • http://www.wsmp.example/productions.ics
  • Mercutio's Theater (MT)
  • Springfield Symphony Orchestra (SSO)
    • Classical Music.
    • http://www.sso.example/calendar.ics
  • Beaufort's Cajun Chop-House (BCCH)

The city's Arts Council (AC) want to be able to make an iCal calendar available that has all of the events from all of the organization merged together.

Basic Features

The calendar-aggregater will have to allow for the following actions:
  1. A list of the calendars to be aggregated needs to be stored. A list entitled "All Arts in Springfield" would contain the following URLs:
    • http://www.smoma.example/smoma_calendar.ics
    • http://www.msg.example/sculpture_events.ics
    • http://www.wsmp.example/productions.ics
    • http://www.mt.example/productions.ics
    • http://www.sso.example/calendar.ics
    • http://www.bcch.example/music.ics
  2. Multiple lists/aggregations could be made, such as a "Music in Springfield" that would contain the following URLs:
    • http://www.sso.example/calendar.ics
    • http://www.bcch.example/music.ics
  3. The members of the AC need to be able to log into the calendar-aggregater and modify the lists of which calendars should be aggregated.
  4. On a regular schedule (such as every hour) the aggregater should download the latest versions the calendars in each list (if changed?) and merge them together into newly updated aggregates.
  5. The resulting aggregates should be available at consistent URLs, i.e.
    • http://www.artscouncil.example/all_arts.ics
    • http://www.artscouncil.example/music.ics
  6. The titles of each event should be rewritten in the aggregate to indicate which calendar it came from, i.e.
    Special Guest - Taj Mahal on the BCCH calendar would become Beaufort's Cajun Chop-House: Special Guest - Taj Mahal on the aggregated calendars.

Extended Features


  1. Instead of creating simple lists of calendars, hierarchies could be created to reduce the management work when adding and removing calendars.
    Lets assume the following example hierarchy. In addition to other aggregates, nodes can also contain calendars:
    • All Arts In Springfield
      • Performing Arts
        • Music
          • BCCH calendar
          • SSO calendar
        • Theater
          • MT calendar
          • WSMP calendar
      • Visual Arts
        • SMOMA calendar
        • MSG calendar
    The BCCH calendar for example, would be included in three aggregate calendars:
    • Music (http://www.artscouncil.example/music.ics)
    • Performing Arts (http://www.artscouncil.example/performing_arts.ics)
    • All Arts in Springfield (http://www.artscouncil.example/all_arts.ics)



Desktop Single-User Aggregater

Situation

A fictional woman named Linda raises sheep and produces her own organic Feta cheese. To sell her cheese Linda travels around several counties each town's farmer's market. Each farmer's market puts up their own calendar with their dates/times -- usually 2-3 times per week each. Linda subscribes her calendar software to all 25 farmer's market calendars, but now has to click through 25 "hide" options to be able to see her other personal and work calendars. Linda would like to combine all of the farmer's market calendars into one.

Basic Features

  • GUI interface for adding calendar URLs
  • Ability to save the aggregated result to the local filesystem
  • Ability to upload the aggregated result to a webserver if desired.

Design Notes

A calendar (.ics) file is simply a text file tags to designate calendar and event start/end:

BEGIN:VCALENDAR
...
BEGIN:VEVENT
...
END:VEVENT
END:VCALENDAR

It may be possible (and indeed, I have seen this in "corrupted .ics files) for a single file to contain multiple BEGIN:VCALENDAR/END:VCALENDAR sections.

As such, it is probably best to keep the notion of a file/url and the methods related fetching the data for it separate from the notion of a calendar. As "calendars" are normally just referenced via URL, it probably makes sense to just treat multiple calendars at a URL as a single group and always merge all of them instead of trying to differentiate them.
Some first thoughts on objects/collaborations:

  • "CalendarFile": A class which corresponds is created with a Url (in the Network-Url category). The CalendarFile would be responsible for retrieving a new version of the .ics file if its internal copy is out of date. It would also create and provide access to "Calendar" objects based on the VCALENDAR entries in the .ics file.
  • "Calendar": A class that could be created with a text-block, "BEGIN:VCALENDAR... ...END:VCALENDAR". Calendar would handle access to the "CalendarEvent"s as well as other properties listed in the text-block.
  • "CalendarEvent": A class that represents an event on a calendar. It would need to provide access to its title to allow for modification of the title when merging calendars.
  • Aggregation: A class that would have a destination Url and a Collection of CalendarFiles. On a given schedule, the Aggregation would check to see if any of the CalendarFiles have changed, and if so rebuild its aggregated list of events and place an updated .ics file at its destination Url.
  • HierarchicalAggregation: Extends Aggregation and provides functionality for building a hierarchy/tree of Aggregations/CalendarFiles.
The various Aggregation engines (List/Hierarchical/Keyword/etc) should be separated from methods for storing/uploading the result (local file/FTP/WebDav).

The MCHttpRepository>>writeStreamForFileNamed:replace:do: method in the Monticello-Repositories category looks like it might be a model for writing to a WebDav server.


Other Comments


Tuesday, 10 May 2005, 1:21:07 pm
Adam Franco
Still To-Do:
  • Finish Aggregation editing interface
  • Implement an Authentication/Authorization scheme


Saturday, 30 April 2005, 5:20:38 pm
Adam Franco:

FileUrl has a bug in which it drops the type that it queries from MIMEDocument. I have submitted a fix to the squeak-dev list: http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-April/091252.html

Additionally, MIMEDocument does not have a listing for *.ics files. I have submitted the addition as an enhancement to the squeak-dev list: http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-April/091253.html

To run the CalendarAggregator and read local calendar files you will need to file in both of those patches.

Sunday, 17 April 2005, 3:38:04 pm
Adam Franco - Add you comments here with *'s around your name. The timestamps and horizontal rules are automatically inserted.

Links to this Page

  • Class projects last edited on 2 April 2008 at 5:20:59 pm by vpn3-144241.near.uiuc.edu
  • Adam Franco last edited on 8 April 2005 at 1:00:57 pm by 140.233.190.101
  • Ralph Johnson's schedule last edited on 12 May 2005 at 7:59:17 pm by 12-221-81-68.client.insightBB.com