[Kolab-devel] event triggered freebusy data generation
Paul Boddie
paul at boddie.org.uk
Tue Feb 25 23:06:04 CET 2014
On Tuesday 25. February 2014 20.34.27 hede wrote:
> Hi,
>
> I asked for documentation to the kolabs freebusy system on the users list.
> If it is really needed to run a cron job every x minutes to generate the
> data (kolab-freebusyd).
I wondered similar things a while ago and wrote a blog post that briefly
mentioned the generation of free/busy data amongst other things:
http://blogs.fsfe.org/pboddie/?p=606
It probably doesn't explicitly mention the cron job that runs the daemon,
though.
> I didn't find any configuration option to let the freebusy data get
> generated on demand and because no one answered, I implemented it myself,
> in "my way. (The "my way" means I expect it to be an ugly hack and not
> accepted upstream. I'm pretty sure there are better ways to implement
> this. At least my chosen names will hurt any english native speaker...)
>
> Instead of running kolab-freebusyd every x minutes, for my use-case it's
> better to start it on demand. So I do so. The freebusy web script triggers
> kolab-freebusyd to regenerate and aggregate the data for the corresponding
> user, if needed, e.g. if the cached ifb-file is too old. If it's not too
> old, the old one gets used and no kolab-freebusyd is triggered. This way
> even on high load systems it won't hurt to use this (with a triggertime of
> 900 it would be like a regular cron job every 15 minutes).
That sounds like a nice idea, and it's probably a common convention in the Web
applications world. I know that I do similar stuff to cache remote resources
in a Web application component I've written (that happens to also have
something to do with calendars).
As for the daemon, I did wonder whether the data was being regenerated for all
users every time, but I didn't get round to investigating what it actually
does. However, I imagine that the eventual aim is to trigger free/busy updates
via an event delivery mechanism upon storing or updating an object in the IMAP
store.
[...]
> Everything using the "kolab-freebusy" web service should trigger the
> generation. I tested roundcube and kontact so far. Clients using the imap
> Freebusy-folder won't trigger anything. That's the drawback.
>
> Btw: Why differ between aggregate and regenerate? And why generate inside
> imap and not directly to /var/lib/kolab-freebusy/? Are there plans to get
> rid of the ifb-files and use imap instead?
I wonder what the CalDAV infrastructure does. Perhaps it's worth looking at
that to see.
Paul
More information about the devel
mailing list