• Manually-entered, "one shot" events. These would have:
  • Name and (optional) description
  • Start and end times, and date
  • Description
• Repeated events. These would have:
  • Name and (optional) description
  • Start and end times
  • Start and end date (optional?)
• Version histories and similar "log data":
  • Name and description
• Query-generated data (general mechanism for pulling in external data)
  • Name and query-generated description
• TO-DO items
  • Name and optional description
  • Optional start and end time (deadline). These would generally have time "now"

• Optional component for graphical rendering
  • Should be passed a Dimension for target size, as well as flag indicating whether component will be added to a container or simply painted.
  • Should renderer definition be part of the calendar item interface itself, or should there be a separate rendering mechanism?
  • We should investigate RenderableSet/ComponentSource adapter as a simple way to do zoomable calendars.
• Optional set of Actions for presentation in toolbars or menus
  • Standard set of actions for editing, creating new ones of the same type, or deleting (?)

1. Defining a "complete" interface, and allowing specific implementations to return null for missing pieces.
2. Defining separate interfaces for basic categories of events. This might be somewhat cleaner, and would also allow for more efficient retrieval since the retrieval method could include a parameter specifying the "minimum" acceptable event types. Once possible set of interfaces would be:
   • CalendarItem, which would include name, description, and other common data
   • DayItem, which would add day information
   • TimeItem, which would add time information

• For a given visualization, it should be possible to merge data from multiple sources. A "composite source" could be used to hide this kind of detail.
• The retrieval mechanism should support partial retrieval in the same way that ListModel, TableModel and RenderableSet do. For sources that support tiling data across multiple objects or pulling data from a database this make access more efficient.
  • Initially this could just be specified by a date range. Eventually we may want to also include some indication of the scale at which the information will be presented to the user, to allow event source implementations to merge data from multiple events if appropriate.
• If the CalendarItem, DayItem, and TimeItem scheme is used, the source for CalendarItems could include methods for retrieving exactly or at least each of these types for a given date range.

• Interval:
  • Timeline
  • Calendar
• Ordinal:
  • TO-DO/event list covering a specific period of time
  • Lifestream-style event stack

Web Editor support

1. A date selector that would allow the user to move to a different date. This could be done either with combo boxes or with a grid.
2. A list of all events (and to-do items) for the selected day. Each of these would be represented as a form with the same fields that appear in the interactive UI, along with a checkbox for marking an event as "to be deleted". Hidden fields would be needed to store information about the original state of the event (to allow replacement). It might also be possible to store the event's list id. Note that care will have to be taken to handle special characters in event names.
3. A form for entering a new event.

Interoperability

• URLs: iCal appends ".ics" to any URL entered into the "Subscribe" dialog. There appears to be no way to add extensions to the FileNameMap used by java.net.URLConnection, so an extra mechanism for mapping extensions to mime-types has been added to bridge.DispatchServlet. If we decide that we want an alternate plain-text rendering (i.e., not rfc2445 format) it might be possible to invent a mime type like text/plain-rfc2445 that is mapped to .ics. Note also that for other calendar tools (like Outlook or the Netscape calendar) it might be necessary to manually append ".ics" or ".txt" to the URL when subscribing.
• Eventually we should support interoperability in the other direction, allowing import or subscription of rfc2445 data. We might be able to find an open-source package for parsing this data. Other issues include:
  • The ComponentView UI will need to be updated to support uneditable events
  • The UI will also need to include a way to turning specific imported/subscribed calendars on and off
  • If subscription of external data is supported, some kind of timeout scheme will likely need to be implemented in the calendar servlet. We should consider a general approach to this that can be used for everything in the server that pulls data from remote URLs.
• The initial implementation only includes to-do items and calendar events from the current year. An iterator in CalendarItemFactory that allowed enumeration of all events would be an improvement.
• A method could be added to the CalendarItem interface that would return an RFC2445-formatted string representation of the item.