[Kolab-devel] extended freebusy-lists (was: Kolab-resource-handlers dependency on Horde libraries)

[Gunnar Wrobel]

As mentioned before the kolab-horde-framework package contains two
patches: one to iCalendar.php of the iCalendar module and a second to
vfreebusy.php of the same module. This is the continued analysis of
the vfreebusy.php patch again meant as a reference.

The patch to the vfreebusy.php file is in principle simple since the
file has not been changed in Horde cvs since the Kolab forked from
Horde. Nevertheless I checked the functionality of the patch to verify
that it is reasonable enough to be included into upstream Horde
CVS. Basically the patch adds support for extra parameters on FREEBUSY
entries in an iCal VFREEBUSY component.

Initially I wasn't certain that this was supported by the iCal specs
but it clearly is: http://www.kanzaki.com/docs/ical/freebusy.html

So the patch should be fine with one remaining problem that I touched
briefly when I did the inital code analysis a while ago:

Bernhard Reiter <bernhard at intevation.de> writes:

>> 2) Merging free/busy attributes results in loss of X-* attributes
>>
>> The function simplify within the vfreebusy.php script looks like it
>> throws away the extra parameters of an event if it finds a new event
>> that overlaps the first one. There seems to be no guaranteed order of
>> preference. I believe this might interfere with the intention of
>> ignoring event updates as they are handled by the freebusy.php script.
>>
>> So I would like to know what the intention of the X-* attributes are
>> and how handling of event updates is supposed to work.
>
> From the logic for the summary display, throwing away when merging seems fine, 
> though I think best would be to have the overlapping peroid to preserve the 
> other information like summary or place in the future.

The current implementation of the vfreebusy iCal component in Horde
does some automatic simplification. It does combine two events with
the same start time for example. Usually it will also call the
"simplify" function automatically that will reduce overlapping busy
periods into one longer busy period. This makes sense as long as you
only work with the concept of a "busy period" that represents an
occupied time without any additional information associated.

Once you start adding additional extra information (like the
vfreebusy.php patch does) the situation becomes more complex: What to
do with the summary information (stored in 'X-SUMMARY' as a FREEBUSY
parameter) if two periods are merged or the longer one is chosen
rather than the shorter one. There is no direct way to combine the
information from both periods into one since Kolab uses base64 encoded
values and so a simple concatenation would cause problems.

The old vfreebusy.php patch had an unpredictable behaviour since it
was dependant on the order it was being fed the busy periods while
simplifying. This is something I fixed and I chose the following
behaviour for the vfreebusy class now:

 - when one period completely surrounds the other period, throw the
   shorter period away.

 - when two periods are overlapping but the extra parameters are the
   same, merge them.

 - when two overlapping periods have different extra parameters, use
   the ealier period completely and make the end point of the first
   period the start time of the later period.

I'll send the modified patch accompanied with unit tests for the class
to the Horde team.

One problem remains: In my opinion the resmgr filter should get
problems with any data loss as described above. The resmgr.php script
determines automatic event updates based on the associated 'X-UID'
parameter of free/busy periods. Now if that information gets lost it
should not be able to determine an iCal message as event update. I did
not go deep enough to fully understand the possible consequences but I
believe that any kind of such data loss is inacceptable to the
resmgr-script.

Did somebody experience such problems when having events with the same
start date for example? Or one short event fully surrounded by a
longer event? I guess these circumstances occur seldom enough but it
should probably be tested.

Cheers,

Gunnar

-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : wrobel at pardus.de                          Dr. Gunnar Wrobel
Tel.   : +49 40 432 72335                      Hartwig-Hesse Str. 12
Fax    : +49 40 432 70855                            D-20257 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  >> Mail at ease - Kolab out of the box <<                 P at rdus
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~