By arnaudq on Oct 06, 2007
The Calconnect presentation on resources (see my previous post) has caught my attention. I will now try to give my own perspectives on the subject.
Given a calendar client from vendor X and a calendar server from vendor Y and assuming standard based protocols, how do I schedule a meeting with 10 people while also booking an available and large enough conference room.
Ideally, we should try to solve this scenario using existing building blocks.
The CalDAV Scheduling IETF Draft is the emerging standard for calendar scheduling. While the iCalendar family of protocols often makes use of terms associated with people ("calendar user", "attendee",...), there is nothing that prevents a resource from being represented as a regular calendar that can be looked up for freebusy info, then invited (the CUTYPE parameter of the ATTENDEE iCalendar property includes values such as ROOM and RESOURCE). And indeed, whether using standard or proprietary protocols, most vendors have adopted that model to "book" resources.
There are still a few things that are special about calendars not associated with users:
- in many cases, responses to meeting invitation should be generated without any human intervention (auto accept), based on some criteria (e.g. double booking not allowed),
- those calendars still need to have a human "owner" that can administer it or respond manually to booking requests,
- the resource needs to have an email address in order to schedule it, although actual emails sent to this address may be ignored,
- ideally, booking a resource should be a synchronous operation (to avoid the race condition of 2 organizers booking the same no double booking resource at the same time),
Now to the discovery part. Here, LDAP sounds like the obvious choice (OK, at least from the point of view of someone working at a company that sells LDAP based solutions...):
- LDAP is the recognized open standard to search for structured and hierarchical objects in a corporate or academic environment,
rooms and other resources already often reside in LDAP and are used by
other applications (e.g. quick address book lookup to find the phone number
of a conference room or its building number),
- LDAP is already used by most calendar clients to find people,
- several major calendar server vendors have already modeled resources as LDAP entries.
third point is quite important as it allows those calendar clients to
offer minimal resource handling without any code modification (as long
as the resources have a name and email address).
So what is missing in my opinion is "just" a standard LDAP schema to model:
- calendar enabled resources,
- most frequently used types of resources like conference room, projector,...
With such a schema, the following scenario becomes possible:
the calendar client of his choice, the organizer composes a meeting
invitation with 10 invitees (selected from his personal address book or
from the LDAP Corporate Directory).
- Calendar client does a CalDAV freebusy lookup for each invitee.
- Calendar client presents the organizer with a freebusy grid view, showing the first timeslot where all parties are free.
- User acknowledges the timeslot and click on a "find conference room" button.
- Calendar client does an LDAP lookup to find the physical location of the organizer (e.g. building number).
- Calendar clients does an LDAP lookup to find all conference rooms in the location retrieved at step 4. and with a capacity of 10 people.
- Calendar clients does a CalDAV freebusy lookup on all conference rooms retrieved at step 6. and picks up the first one that is free for the selected timeslot.
- Calendar client automatically adds that conference room in the list of invitees.