[Kolab-devel] extended freebusy-lists

[Gunnar Wrobel]

Hi Bernhard,

>> 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. 
>
> could we keep two overlapping periods according to the freebusy standard?
> Otherwise we might consider deviating from the standard for the xfb files.

Yes, indeed there is no real reason to merge periods. It would be
perfectly ok to keep overlapping free/busy periods. The current
free/busy implementation does use the start time as unique key for the
periods so there is guaranteed data loss in these cases (longer period
gets chosen).

>> 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.
>
> A complicated one would be possible, I read from this.

I guess one would assume that all extra parameters are base64 encoded
and that would not be a valid assumption within the iCalendar
library. The only thing the library could do, would be to concatenate
the periods with a separator and then you would need to modify the
callee (freebusy/resmgr) so that it deals with the possibility of
parameters joined this way. The better solution is definitely to not
merge the periods at all as you mentioned above.

>> 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.
>
> I guess so as well.
> Without giving it much though I would assume that resmgr should use
> a different cache anyway. And I thought Martin's large patch would do this.

The cache that has been added now is an intermediate cache but the
handling of the iCal data uses the iCalendar module from
Horde. Actually I guess there is no way around this.

>> 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.
>
> You are more proficient with the code. Try to create a simple test
> case for the situation. I know that there are some dark spots in the fbview 
> handling and also in the invitation handling.

After reconsidering I believe the best solution would be to modify the
vfreebusy class so that no periods will ever get lost (only in case
one really calls "simplify). This cannot be provided by the current
implementation but it should not be too hard to modify it. Then the
freebusy/resmgr scripts should be fine. The call to simplify would
still result in the behaviour I described in my last mail but the
callee would know exactly that it risks data loss when calling this
function. 

Test case should be fine. The pear utilities for testing are actually
ok though doc testing in python is certainly nicer by far ;)

Thanks for the comments.

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