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

[Bernhard Reiter]

Hi Gunnar,

sorry for the late reply. 
I have been away for a few weeks (yes some vacation as well).

Am Donnerstag, 15. Juni 2006 17:35 schrieb Gunnar Wrobel:
> Actually the vfreebusy part is not as easy as I thought initially. I
> do have a few questions concerning the original intention of the code
> changes.
>
> The iCalendar package of the Horde framework (and specifically the
> vfreebusy.php handler within that package) has been modified for the
> Kolab project to support setting additional parameters on free/busy
> periods. Usually a freebusy object only allows setting some basic
> parameters like the e-mail address of the corresponding organizer and
> a set of free/busy periods that are only characterised by their start
> and end times.
>
> For kolab the free/busy periods have been extended to allow setting
> parameters beyond the start and end dates. This is being used within
> the free/busy class to store "X-UID" (==uid), "X-SUMMARY" (==summary
> if event is public), and "X-SID" (==scheduling-id if present) on each
> period.
>
> Within kolab only X-UID and X-SID seem to be used in order to filter
> updates to events. Is this correct? 

I believe so, but I am not extra sure if this is used or useful.

> Is that the main intention of 
> allowing additional attributes to the free/busy periods?

No. 
The intention is to modell a use case.
People would often like to see an overview about the calendar of their group.
Giving everybody full read access to all persons within the group is not the 
best solution as this detailed information is not necessary. Also Outlook has 
problems dealing with many calendar folders. Thus the idea was born to use
the web for this and add the necessary information to an extended freebusy 
view. This view could also be another privacy layer.

> X-SUMMARY does not seem to be used anywhere, but groupware clients
> could access this information if they fetch the *.xfb file. Which
> clients use this information?

/fbview currently uses it.
If you have read access to a user you are adding to the view, you will see the 
summary in the tooltip of marked busy time.

We are currently thinking about
a) to add the place of the appointment as well
b) how to model access to the xfb information, currently access is too 
restricted to make it useful.

> There are two problems that I do see with these extended attributes:
>
> 1) They are erased before ever being accessible
>
> There is a section in the freebusy.class.php script that tries to
> export the vCalendar object.
>
> freebusy.class.php:
>
>     $xvCal = $vCal;
>     $xvCal->addComponent($vFb);
>     $vCal->addComponent($this->clearExtra($vFb));
>
>     // Generate the vCal file.
>     $result = array( $vCal->exportvCalendar(), $xvCal->exportvCalendar() );
>     return $result;
>
> The problem with this code section is that the addComponent call does
> a pass by reference
>
> iCalendar.php:
>
>     function addComponent($component)
>     {
>         if (is_a($component, 'Horde_iCalendar')) {
>             $this->_components[] = &$component;
>         }
>     }
>
> So the $this->clearExtra($vFb) within the freebusy.class.php script
> effectively kills all additional attributes on both $xvCal and
> $vCal. Exporting results in equeal strings and the attributes are not
> retained.

I have not checked yoru code analysis,
 but I can see the summaries in the xfb lists,
so they must not completely be gone.

> 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 overlapy the first one. There seems to be no guaranteed order of
> preference. I believe this might interfere with the intetion 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.

Thanks a lot for your well written analysis!
We are still bad reacting at your analysis, this is partly because we lack the 
developer time. Still your help is appreciated a lot, even when we react 
late.

Best,
Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1310 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20060707/a4e7523d/attachment.p7s>