I've committed that one-liner, so if this works for others then we can 
close this issue

Okay, here is a workaround which doesn't touch the core Horde 
implementation. The idea is to fool the error handling which prevents 
using the storage driver to retrieve an URL. So we map an existing 
Kolab LDAP field to freebusyUrl. Horde won't find f/b data under the 
URL, but at least the URL is valid. So we continue with the processing 
towards the storage driver which will finally provide the f/b data.

It would be good if Kolab could provide the URL in LDAP, but this is 
another story.



The file to be changed is turba/config/sources.php.dist



--- sources.php.dist.orig       2005-02-10 14:52:47.128198440 +0100

+++ sources.php.dist    2005-02-10 14:54:52.272173664 +0100

@@ -566,6 +566,7 @@

              'cellPhone'         => 'mobile',

              'fax'               => 'fax',

              'notes'             => 'description',

+            'freebusyUrl'       => 'kolabHomeServer',

          ),

          'search' => array(

              'name',



Please apply the change to CVS.

After another session I've pinned down the problem as follows:



The critical section in the code is in kronolith/lib/Kronolith.php in 
the lines 843-858. There is an attempt to get the f/b URL from an 
addressbook, which doesn't seem to work with a Kolab backend. My 
understanding of the code is, Horde should just continue and use the 
storage driver to get the f/b data. That implementation is correct for 
a Kolab backend. However, I didn't get the code in the storage driver 
executed. Once I commented out the lines 843-858, I could read f/b 
data from the Kolab server and everything else worked as expected.



I hope this analysis is of help for fixing the real problem which 
seems to be behind the mentioned lines of code. Commenting it out 
won't be an option for Horde on another backend. ;-)

The first error message comes from the fact that you have that contact 
in two address books. This should have been fixed already, but 
probably only CVS yet.



The second messages means that you don't have this contact or this 
contact's free/busy url in your address books at all.

To provide some more details:



kronolith/lib/Storage/kolab.php looks good:

     function search($email, $private_only = false)

     {

         global $conf;



         $fb_url = 'http://' . $conf['kolab']['imap']['server'] . 
"/freebusy/$email.vfb";

         $vfb_text = file_get_contents($fb_url);

         if ($vfb_text === false) {

             return PEAR::raiseError(sprintf(_("Unable to retrieve 
free/busy information for %s"),

                                     $fb_url), KRONOLITH_ERROR_FB_NOT_FOUND);

         }



I think that this method is never called, I can't find appropriate 
requests to the f/b URL in my Apache logs. So far I've tracked it down 
to the class kronolith/lib/Kronolith.php and function 
getFreeBusyUrl(...).

While other clients as well as the Kolab 2 built-in fbview access the 
F/B information quite fine, Horde is not able to read or process that 
data. Creating an event for "mustermann" and inviting "video" gives 
the following error messages:



Error retrieving free/busy information for mustermann@osp-dd.de: More 
than 1 entry found

Error retrieving free/busy information for video@osp-dd.de: No 
freebusyUrl entry found for video@osp-dd.de