[Kolab-devel] event triggered freebusy data generation

[Thomas Brüderli]

Paul Boddie wrote:
> On Friday 28. February 2014 10.21.27 hede wrote:
>> I would prefer a solution where the imap daemon itself triggers an event
>> with every new upload to a folder with type "calendar". This solution
>> would be independent from any client-support. Even deleting events with
>> some pure email-only-client would be fine.
> 
> Currently, these free/busy resources are generated by the daemon and served by 
> a PHP resource that seems to just forward this static data, but would it not 
> be sufficient to generate the resources entirely using some kind of dynamic 
> resource (PHP, other Web "script" mechanism) instead?
> 
> In other words, instead of performing the free/busy resource generation in 
> kolab-freebusyd, the script published at /freebusy would dynamically generate 
> (and cache) the data for the requested .ifb resource. Was there a reason not 
> to do this, such as doubts about performance or reluctance to duplicate 
> functionality already written in the KDE-derived libraries?

Freebusy data collection and caching (using PHP and Horde) is what we
had in Kolab 2.x and you all know how that ended. Think of a user with
several calendar folders and subscribed to shared calendars, iterating
over all the events on demand doesn't scale. Even caching with cache
validation checks has its downsides.

As Jeroen van Meeuwen already pointed out, subscribing to update
notifications right in Cyrus IMAP and rebuilding freebusy data upon
change is the preferred way to go. With that in mind already, we decided
to build the kolab-freebusy daemon which is still needs some
improvements and polishing. But now as Cyrus 2.5 is available, work can
continue.

Using KDE libs for this was certainly a convenience and terms of
performance, C++ isn't a bad choice for this kind of job.

And regarding the questions why free-busy data is also stored in IMAP,
this was meant for offline-capable clients such as Kontact which can
pull the data using the existing IMAP synchronization and access it locally.

> I'm tempted to have a go at writing a Python script to dynamically generate 
> free/busy resources from the IMAP store.

We certainly cannot stop you from doing this but I don't see this to be
a sustainable path.

> P.S. I see that the iRony component generates free/busy information for CalDAV 
> clients, but I guess that it just accesses the files in /var/lib/kolab-
> freebusy and forwards this data, too.

FWIW: iRony first tries to fetch data from the pre-generated .ifb files
and has a fall-back implemented to iterate over a user's calendar and
build freebusy data on-demand.

Kind regards,
Thomas