[Kolab-devel] event triggered freebusy data generation

[hede]

Am Mon, 03 Mar 2014 08:54:56 und 10:23:08 +0100 schrieb Thomas Brüderli <bruederli at kolabsys.com>:

> Freebusy data collection and caching (using PHP and Horde) is what we
> had in Kolab 2.x and you all know how that ended. 

nope, not me, I never used freebusy in 2.x, but I can imagine.  ;-) 

> Think of a user with
> several calendar folders and subscribed to shared calendars, iterating
> over all the events on demand doesn't scale. 

I guess the user has to wait some time on his first call, but the load on the server should be still less as with regular update intervals?

> Even caching with cache
> validation checks has its downsides.

Yes, apart from the time a user has to wait there are some downsides shared with a regular running cron job. For example obsolete data if one of the (shared) calendars has changed in the last minutes.

> 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. 

Yes. That's the best solution I think. 

> 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.

*thumb up*

> 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.

I do not see the difference in triggering such a daemon with cron or a web script. 

> 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.

That's the reason for using "triggertime" in my small hack starting this thread. With a "triggertime" in the range of the original cron interval, the load on the server cannot exceed the load it had with the activated cron job, where it is much lower in normal operation. 

I will use my hack until there's a stable freebusy daemon using notifications with cyrus 2.5. (And btw. till then I have to find a way to upgrade cyrus to 2.5 without smashing my imap storage.)

regards
hede