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

[Bernhard Reiter]

Hi Gunnar,

On Thursday 23 November 2006 14:31, Gunnar Wrobel wrote:
> 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.

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

> 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 

Good, thanks!

> and I chose the following 
> behaviour for the vfreebusy class now:
>
>  - when one period completely surrounds the other period, throw the
>    shorter period away.

Not good for the additional data I guess.

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

Okay.

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

Also not really good I guess.

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

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

Bernhard

-- 
Managing Director - Owner, www.intevation.net       (Free Software Company)
Germany Coordinator, fsfeurope.org       (Non-Profit Org for Free Software)
www.kolab-konsortium.com   (Email/Groupware Solution, Professional Service)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20061124/a4f0c343/attachment.sig>