[Kolab-devel] event triggered freebusy data generation

[Thomas Brüderli]

Thomas Brüderli wrote:
> 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.

And even more important: collecting freebusy data from any user's
calendar requires admin authentication on IMAP. And from a security
perspective, it's more safe to have a daemon running on the server
operating with admin rights rather than a publicly accessible web
service being able to access anyone's mailboxes.

And with the freebusy web service serving static files or delegating
generation to a paced daemon running in the background makes it less
vulnerable against overload and DoS attacks.

Please bear these things in mind when you consider writing an on-demand
python script for delivering freebusy lists.

Kind regards,
Thomas