Re: [Kolab-devel] event triggered freebusy data generation

On Monday 3. March 2014 08.54.56 Thomas Brüderli wrote:
> 
> 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.

I don't disagree with the above. Since the IMAP store is effectively opaque 
with regard to the details of the event objects, there's no efficient way of 
querying them for a given time period, although I recall some mention of 
Xapian and I can envisage a way of building an index based on extracted 
datetime information that could then be queried efficiently. The Xapian index 
would need to be updated just like any "rebuilding [of] freebusy data" would, 
however.

If Cyrus can offer IMAP querying, say, based on indexed content (such as an 
xCalendar element), that would already make some kind of live querying tool 
much more efficient. Otherwise, some kind of index builder could be written to 
achieve the same thing.

[...]

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

Actually, I don't really wonder about this. Kontact is capable of publishing 
its own information - this is part of the original iCalendar RFC if I remember 
correctly - and I see that it also supports pushing using HTTP, too.

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

For me this would just be an exercise in working with IMAP and Kolab: I'm not 
advocating this seriously as a replacement for the daemon...

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

...but it's clear that a selection of approaches could still be useful to 
people, as we're already seeing in this thread. I understand the need for 
privilege separation and load control, and the latter may be the most pressing 
concern for some of the people on this list, but there's also the issue of 
latency to consider as well.

Paul