Calendaring requirements refined into the basis for a critique. (In progress.)
Given the raw list of requirements, here is a rough attempt to categorise those requirements and identify a basis for a critique of existing specifications and products.
If there is something missing here, please get in touch.
All life is calendaring. Or something like that. What do people want from calendaring applications? Pretty much everything. That's why it's an interesting subject: one can envisage calendaring having a great deal of overlap with most of our daily lives. We look for meeting scheduling, to-do list management, shopping lists, resource allocation, burglary victims, holidays, issue tracking, deadlines, the list is endless. And we all have the nagging feeling that this is something that could be handled by a personal agent, something we can get at on our Palm Pilots, over the phone, via the Web, by email, and so on. We all want somebody - or something - to organise our lives.
The point of this preamble? The observation that has to be made is this: that we're unlikely to satisfy anyone with a closed set of specifications. Thus we arrive at these fundamental requirements: I'd assert that all reasonable designs should satisfy these criteria if they are to have a future.
We expect a calendaring system to cope with the needs of an entire enterprise (or more) - in a University environment, for instance, this may mean tens of thousands of users, several thousand groups, several thousand (or more) physical resources, all of which we wish to schedule.
A centralised solution may seem to solve a lot of problems, but there may be a limit to the number of calendarable objects that a single instance of a calendaring server can cope with at once. Clearly, however, there needs to be a better reason to wish to distribute calendaring service - since distributable protocols and data models have a much greater level of sophistication, and there's much more to go wrong. For once, politics comes to the rescue. There may be a requirement for scheduling across the enterprise boundary; in a centralised system, who would 'own' the server?
There seem to be two viewpoints on the organisation of calendaring software. The first takes a monolothic worldview: there is a single calendar, and calendarable objects enter events into it (along with visibility and management information). The second is that every calendarable object has its own calendar, and the scheduling of an event requires the cooperation of those calendars. (Note: this is a description of the logical architecture; an implementation might use a shared database to manage the individual calendars of a group of calendarable objects.) While the latter is an appealing notion, it may turn out that a reasonable organisation is to have "connected islands": monoloithic enterprise- or department-wide servers communicating between themselves when the need arises.
At the outset, we do not reject any of these models, providing they have the requisite functionality.
We also note that human intervention might be sought at many stages of a scheduling operation.
Get used to writing programs this way. When half of the computers you're talking with are on Mars, it'll all be like this.
It's clear from the above that a fundamental need for a calendaring system is a (distributed) user/group management layer that can identify "calendarable resources" - people, roles, groups, resources.
For brevity, we use the term "calob" to abbreviate "calendarable object", the entities who are the object of a scheduling operation.
How does a user of the system locate calobs? They might appear in a directory listing; he might find them via a search engine, or by locating addressing information on a web page.
There are a number of existing technologies which support all kinds of discovery: LDAP, PGP servers, etc.
After a calob C has been discovered, it must be registered with (introduced to) the scheduling system of agent A if A is to have anything to do with it. Various kinds of introduction are possible, and we want to support them all:
When a calendar service receives a scheduling instruction or query, it has to corectly identify the source of that communication, and process it appropriately. The kinds of things that might be subject to access restrictions are as follows (this is not intended to be a definitive list):
"Disappearance" is what happens to things given long enough. No matter what the W3C may say, URLs don't point to persistent content; whether the expactation that they should is a reasonable one is, however, an argument for another time. We merely observe that people change jobs, change email addresses, change social security numbers, change phone numbers, and often don't tell everyone (anyone) that they've done so. So these requirements are to do with practical resiliency and the preservation of history.
It's worth pointing out that most of the headaches and complexity here will disappear if the calobs are managed as part of a centralised service. Consider X.509 certificates (stored in LDAP) versus PGP: the former essentially has a centralised management; the latter is a chaotic mess. What has been described above really needs a capability-based system to manage it.
Some observations: for multi-party scheduling, our only requirement is that all parties can agree on the time, and communicate using that time as a basis. There already exists good protocols for synchronising clocks over a network.
Some people want more capability than that: the ability to use different calendars, different time-zones, etc. I would suggest that these are, in the first instance, properly handled by a calendaring agent/user interface. Higher-level reasoning about complex human calendars might be desirable; but if we can side-step timezone considerations by punting the cost of such calculations onto an agent, so much the better.
Also, we note that from a pragmatic point of view, we're looking to schedule meetings, etc, not to record subatomic events. For the former, a quantisation of time into 15-minute chunks seems reasonable. For the latter, we'd need nanosecond (and beyond) resolution. We expect that, given a modular event model, some people might use it to expose the results of their physics experiments. We don't see the inability to do this, however, as a failing of the calendaring model - just as an "it would be nice if...".
One broad division of calendarable events is into point events which occur at one instance in time (for example, deadlines), and intervals which have a duration. To add complexity, a three-day meeting can be viewed in two ways: as a continuous interval, or as the union of three discrete intervals (since few people have the stamina to attend 72 straight hours of anything).
Some things happen again and again. For example: at work here we tend to have a departmental staff meeting every other Monday.
From one point of view, a calendaring protocol doesn't need to know about the generation of these repeating events; it just needs to know that they exist, and be able to answer questions about them. However, we may have more general requirements (for example, "meet once a month") which might involve scheduling a once-monthly event which initiates the scheduling of that month's meeting (!).
The point of view where a single event is an instance of another is one example of nested events.
As mentioned above, some events may be single intantiations of a parent generator. In principle, this construction may be arbitrarily nested.
Events may be nested in other ways. The example above of a compound interval might be expressed with three simple intervals, all considered parts of the compound. This would permit, for example, the representation of the fact the "Jan managed to attend two days of the three-day meeting".
The data-model requirements for calobs follow from the discussion above.
From here on, needs completion: bring in stuff from the requirements
It's worth pointing out that ACLs based on identity and/or group membership implying a capability are the obvious consequent of a user transmitting proof of their identity and group memberships to a calendar server. ACLs including (not group member implies capability) or (group member implies block capability) require more implementation work, and evaluating them separately involves a trusted path to determine accurately the candidate's membership status.
Rather than specifying a (Turing-complete?) language for ACLs, event reoccurances, etc, we could simply take the view that to perform a function f, we only need the address of an agent that can perform f for us. We supply it with the appropriate parameters (including a proof that we are permitted to ask such a question) and it returns the results. The consequence of such a model is that we leave open the option of arbitrarily complex computation at appropriate points. This is both a pro and a con, of course.
Scenario: recurring events need to be triggered/generated. These aren't initiated by a calob - the generator takes on a life of its own. In general, we perceive the need for events that trigger the generation of events (and so on). An event can have zero or one "generators".
Possibility: relax "linear in number of participants" requirement if gains are available elsewhere: eg, zero-knowledge scheduling.
@@ Freebusy classes: eg, "available for phone meetings", "available in Boston", etc.
Scenario: synchronising with a Palm