Planet Ergo

This last week and a half or so, I've been working on implementing Resource Management based on the new Kolab XML format version 3, which uses xCal for events.

Individual Resources

Individual resources -that is to say, the way I've implemented them- consist of a Calendar folder in IMAP (a Kolab Shared Folder in IMAP, with type 'event'), name ("label", if you will), and a recipient email address. Events for which a resource is invited are added to the relevant Calendar folder. For example, a resource "Volkswagen GTI" (of type "Car") gets recipient email address: resource-car-volkswagengti@example.org, and a shared event folder "shared/Resources/Volkswagen GTI@example.org".

Resource Collections

As described in the Resource Management article, we are considering resource collections ("cars", "confererence rooms") to be eligible for selection when a user seeks to make reservations for such resource. This enables users to indicate they want to make reservations for "a car" rather then a specific car. I've implemented this by collecting the individual resources in a collection as groups, which naturally have a title (the common name of the group, in fact).

When a user selects such a resource collection, and sends out the reservation request iTip, it is sent out to the canonical address for the resource collection (in this example resource-collection-car@example.org). A Kolab content filter named Wallace detects the fact the message contains an iTip, and that resource-collection-car@example.org (one of the attendees) is a resource collection.

Wallace (or actually, its 'resources' module) then takes the individual resources that are in the collection, and detects whether there is a conflict between the existing events scheduled for each individual resource.

If none of the individual resources have an event already scheduled, Wallace randomizes a selection and will attempt to use that resource instead of the original resource collection. In true iTip-style, this means a delegation response needs to be sent back to the organizer, with the delegator being the resource collection, and the delegatee being the individual resource selected.

This allows a user to invite a resource collection, but indicate a preference for a particular resource - though not implemented yet. Think, for example, a user could invite resource-collection-car+resource-car-volkswagengti@example.org.

Overall Thoughts

The implementation (of the aforementioned) is not fully done yet. I have a bunch of TODOs remaining:

L10n and/or i18n

On my personal TODO list is to allow this folder path to be localized, so that for an installation that has German configured as its locale, the folder name becomes "shared/Ressourcen/Volkswagen GTI@example.de", or, in Dutch, "shared/Middelen/Volkswagen GTI@example.nl". I'm awarding myself bonus points if I can also make the "resource-" and "resource-collection-" be localized somehow, though I realize it is in fact an arbitrary prefix altogether and could be made to dissappear.

The name used for the actual folder (as well as the transliteral, normalized ascii string for the email address) is a name the user supplies in the Kolab Web Administration Panel.

Delegation, Cancellation

While I pride myself these actions or iTip message types can be implemented quickly, it's not actually been implemented yet.

Caching

In my tests (sending tens of thousands of randomized reservation requests around), it can take Wallace a significant chunk of time to resolve conflicts as it operates against raw IMAP and thus has to retrieve all events, one by one, at least until a conflict is detected. This clearly doesn't scale, so Wallace will need some caching. I'm tempted to allow re-use of the caches that Roundcube already maintains, though there's little spare room for large quantities of events that users normally don't need caching for.

Naturally, there would also be the opportunity to use existing Free/Busy information, if any, and/or to create and/or update such Free/Busy information or trigger such update to happen. The backend for this Free/Busy information could be using the same caches as well...

Long story short, I'm not done with regards to caching and event conflict detection quite yet!

Recurring Events

Recurring events, or event occurrences to be exact, are not yet being parsed (fully). With libkolab however, it should become relatively easy to do with the existing codebase now still a part of kcalcore (from KDE).

Reservation Request Responses

The responses sent out to reservation requests do not look as pretty as I would like them to look, regrettably. I think the user experience (compared to what I have now) could be greatly improved.

To stick-shift, or not to stick-shift.

There's no design yet for parameters to a resource to be stored and taken into account, so that a user might select "a room with 6+ seats, a beamer and a wired internet connection for the speaker / for each participant". Similarly, Wallace might take into account a general reservation request with 7 attendees should not be allocating a room with 4 seats.

Users Should Not View the Resource Calendars

See the following screenshot for why users should not be able to access the resource calendars directly; Firstly, the number of resource calendars to a deployment be a very large. Secondly, these resource calendars may just contain too many events.

That is to say, of course, a particular type of user could get access to the resource calendar itself, such as a secretary, but it would likely be write access.

Click to enlarge the image.

It's Tempting to go Out-of-Specification

It's tempting to go outside of the specification, and attempt to automate things further. If a user were to propose a meeting time and no room is available, what could Kolab do? Kolab could issue a counter-proposal changing the event to a time a room is available, for example. Kolab could also CANCEL the event.

Also, when a user selects a resource collection (such as, in this example, "a conference room"), the specification says to send a delegation iTip message back to the organizer only. It is then, according to the specification, up to the organizer to choose whether or not to send out an updated event (with the actual room) to the other attendees. But, of course, a "room" may be bound to a physical location, and I would think one would want the attendees to be updated period, and not leave the choice whether or not to send the updated information out to the attendees to the organizer.