Any Statement on Calendar Standards Support?

[steinb]

I am a system administrator at a german university's computer science institute. We are currently taking a closer look at various groupware and calendaring systems, because we have a strong user demand for a working solution so that people can manage personal and public calendars and arrange apointments (as a first step for staff members, but in the future hopefully also with external partners).

As far as I can tell, it is widely accepted that iCalendar (RFC 2445) is the right choice as the data format for calendars, apointments, tasks, and journals (although implementations greatly vary regarding the supported subset, e.g. related to recursion rules or timezone support, for example). Similarly, exchanging ICS snippets through email seems to be an acceptable and accepted solution, and CalDAV (RFC 4791) support is getting better - slowly but constantly.

Another proof that this architecture is making good progress is the fact, that RFCs 2445bis and 2446bis are close to being published. If you look into it, you'll see that the architecture is really complex :-/ but on the other hand it brings standards specifications for a couple of features that are really, really cool. :-)

Yet another proof is that the CalConnect consortium is growing and the outcome so far looks promising.

Now, I would really like to know, whether there are plans on taking the bitter pill to switch to these IETF standards (full iCalendar support, CalDAV client and CalDAV server support), or whether there are no such plans at this time. I can imagine, that such a switch would be anything but trivial, but in the long term, it seems to be the right choice, I guess. I found an indefinite statement on the OX roadmap for 6.10, but it is says nothing about concrete standards support.

To be honest, at this point in time, I would prefer using the Darwin calendar server which is quite cool, but there seem to be no Web/AJAX clients as cool as the OX UI (in fact, I cannot find any CalDAV Web client at all worth mentioning).

(Similary, I wonder why OX does not use LDAP for users and groups, but that's another quesiton.)

Thanks,

-frank

[Martin Heiland]

Hi Frank,

we're eager to support commonly used RFC specifications and we already support large parts of the iCalendar standard. Since the iCalendar format is not exactly a effecient way to store huge amounts of data and access them quickly on a system with a huge amount of users, our primary data backend is and will be a relational database management system. We already offer interfaces to read data stored at the database as iCal, try /servlet/webdav.ical, see API docs for parameters. We put major effort to this interface to gain a more compatible implementation but as you already mentioned there is a wide array of client and server implementations that differ in terms of completeness and correctness. When you're evaluating this interface and may find any problems please report them back.

The main drawback here is that this interface is read-only right now and we are working on write support. The cause for this lack of functionality is that we do not implement the CalDAV standard and raw ical cannot be separated to single objects so a client will push the whole calendar through that interface on any change of a appointment at its calendar which leads to considerable load on our calendar backend. Write support is generally available, but not via a WebDAV servlet, we have a import module at the configuration area of each user as well as the possibility to create appointments from ical attachments on E-Mails. The good news is that we have identified this problem and are planing to support write operations in one of the next releases. However, our major interface to the OX server is our HTTP API and there are already some internal and external developers building connectors to popular PIM clients (like Evolution, Lightning, Apple iCal). You can track the improvement of those clients here at the forum, the Apple iCal support is made by OX itself, a partner is working on TB/Evo. However, we are aware that not everybody will use our API and we know that standards support is critical for interoperability so don't take this as an excuse - we also want proper support for relevant standards.

About the LDAP storage for user data, well we had that with OX5 since it was born as a enterprise product primarily - OX6 was born at the hosting market where LDAP and other directory services are not as common. We're able to use LDAP/ADS/eDir as authentication backend and source for contact data but the OX contact data source is consistent with calendar/infostore/task data at the database. We also have tools to synchronize LDAP data to the OX database so that you don't need to manually change two data and authentication sources. This solution may not be perfect right now but if there is major demand on a ldap-only contact and credential storage i'd not say that it is impossible.

General talking about releases, the current roadmap shows 6.10 in Q3 2009 but we will change this release cycle to present a set of new features faster to implement a better feedback loop to our development cycle. I've forwarded this thread to our Product Management team and other people in charge for the roadmap and RFC support since i know that the desired features you're talking about are already on our minds and partly on the roadmaps.

Greetings

[steinb]

Hi Martin,

thank you very much for your detailed response and your fair statements.
I think, we'll keep on evaluating different approaches.

Thanks,

-frank