The calendar store is agenda-centric. Events are accessible through agendas, and agendas are the first class objects that people subscribe to.
Goals include:
Each agenda has a set of attributes and 0 or more events associated with it. Attributes include:
The hierarchical name of the agenda is for ease-of-use only, so that we can quickly aggregate multiple agendas together (such as "all official agendas"—see conventions). Agendas may be freely renamed between hierarchies. The hierarchy may control where new agendas can be created.
Agendas group related events.
User searches also create "virtual agendas": agendas that don't exist in the data store (thus have no ACLs, no name, no owner) but contain events grouped by the fact that they match the search criteria.
A virtual agenda could be a union of one or more hierarchical agendas, such as a user's subscription list or a "this agenda and everything below it in the hierarchy".
The lower level code will give identical or nearly identical interfaces to the user interface for manipulating virtual agendas and hierarchical agendas.
Any search results in a virtual agenda.
An event is an iCalendar VEVENT object. It has primary attributes that represented by their own database column and contain specific, normalized data and secondary attributes (everything else). The secondary attributes will be stored in a BLOB column formatted either as XML or in iCalendar-syntax.
It has many attributes from the iCalendar specification. Not all of these attributes are necessarily accessible via the UI; some are only present to allow for future expansion, if desired.
It also has local, CMU event attributes, all of which are secondary attributes.
An event is a member of one or more agendas. One agenda will be designated the "primary" or "owning" agenda, and those with write access to that agenda will be able to edit the event.
(How to determine the owning agenda?)
Recurring events will be supported if the user interface for entering them gets done. They will likely be exploded on entry, losing or rendering inaccessible the recurrence rule that created them. Some association between the events will be kept to enable mass deletion and editing of common fields.
Proposal: refuse entry of any recurring events with more than 100 occurences. (We'll set a year boundary for 2030 or something for yearly events.)
Related events that aren't the same event can be grouped via an agenda.
choosing an event and creating a clone off of it?
A "principal" is the authenticated entity accessing the calendar. Any user can act as their own principal or as one of their groups; their rights are the union of all rights.
Textually, users will be represented as user=leg. Groups will be represented as group=acs:folks. It is anticipated that the group membership for a principal will be determined when that principal authenticates.
Special principals include anyone, anonymous, and administrator.
Not determined: should these just be agendas or should this be a different sort of beast?
If these are just agendas that anyone can post to, the UI will have to distinguish agenda types. It simplifies subscriptions to types, though.
Current thought is that types will also also be hierarchical, ala the Northwestern Event Calendar.
There will be a table of locations, hopefully prepopulated by "official", "on-campus" locations. Some sort of canonicalization algorithm will be used in the UI to correct "CyH 234" to "Cyert 234". Other locations will be added to the table when entered, but marked as ad-hoc so that they won't be used in canonicalization.
to determine: should we store buildings and rooms separately?
Each principal may have zero or more subscribed agendas. It is anticipated that the default portal module would display all the events that are on the union of these agendas.
Should subscriptions be allowed to a hierarchy of agendas? (Seems very useful; seems somewhat annoying to implement.)
Should subscriptions be allowed to non-agenda objects?
It appears to be nonsensical for group principals to have subscriptions.
Some things are aren't enforced by the code but by how we use it.
All agendas under a particular hierarchy can be considered "official". These would be the default subscription for "anonymous" and, by default, anonymous searches could return only these events.
We'd probably start out by having people request agendas from the Help Center. Any "group" on campus could request an agenda and give some userids to add to the access control list; the help center would determine whether it was ok to create the agenda at that part of the hierarchy.
Later agenda creation could be delegated. Part of the agenda hierarchy space could be self-created (a la graffiti).
Events have no associated ACLs. All access control is enforced at the agenda level.
It is anticipated that top-level agendas (agendas with no "parent" agenda in the hierarchy) can only be created by administrator or anyone with administrator rights.
Sub-agenda creation will be controlled by an access control on the immediate parent agenda, or may be done by any administrator principal.
One ACL right shall control event creation; a user with the rights to create an event owned by that agenda.
A different right on agendas will control event insertion: the ability to add an existing event in the store to a given agenda. If a user can read an event and has insert access to an agenda, they may add it to that agenda.
Agendas may have read rights; there is no schedule for this to be implemented.
Anyone with edit access to the primary agenda of an event may edit that event. If they have create access to another agenda, they may change the primary agenda.
Anyone with delete access to an agenda may delete any event from that agenda.
What happens when an event is deleted from its primary agenda?
The eventual goal is to model the interface by drawing a state diagram of windows, showing which actions cause the view to switch to another window.
Windows that may be needed:
Features on the Large viewing window:
volume-centric; volumes can be attached to the filesystem namespace 0 or more times.
CMU volume names have developed into a hierarchy by convention (the fileservers do not interpret or enforce the hierarchy): user.leg, src.sendmail.025, x86_l22.sendmail.025, etc.
Hopefully, BEEP utilizing the SASL GSSAPI mechanism and a profile of our own devising. This will allow easy extension, on either end, into CAP or a CAP-like protocol if we so desire. It is anticipated this will be done with an existing Java BEEP package for both ends.
If BEEP turns out to have unexpected technical difficulties, we will use HTTP, sending XML documents in response to GET/POST queries. (Some sources seem to call this the "REST" model.) Authentication will be done using TLS with client side certificates, and the portal will be trusted to proxy for all users. The server (event calendar engine) can be implemented using Java servlets; the client (portal) using an Epicentric HTTP API.
The event calendar is divided into several parts:
The communication between the frontend API and the backend engine is via BEEP. Due to the time crunch, the actual BEEP messages won't have much resemblance to CAP but share some concepts. The following commands are anticipated:
The client API will be closely mapped to the commands but will take java objects instead of iCalendar strings.
Some tracking milestones so that we have a clue that maybe we'll deliver something that might be usable by some time in the late summer:
In the below exerpt, there's two separate events being shown: one starts May 6th at 10:05 pm and lasts 3 hours (thus until 1:05 am on May 7th) and the other starts May 7th at 10:05 pm. The user interface displays them identically. What, if anything, should we do about this?
| 10:05 PM | @ Seattle | |
| 10:05 PM | @ Seattle |