Horde development

From Kolab Wiki

Jump to: navigation, search
The content of this page is outdated. The Horde development was completed some time ago and was now abandoned in favor of Roundcube.
If you have checked or updated this page and found the content to be suitable, please remove this notice. Alternatively, check docs.kolab.org for more recent information.

A new Kolab specific framework for Horde has been developed since 2005. The framework provides Horde with reliable access to the Kolab server for the first time.

The following subsections discuss the different parts that are required to make Horde work together with a Kolab server. In addition any remaining problems or possible improvements are listed.

You might also wish to consult the primary project page for Horde/Kolab.


Project status

The new framework was nearly finished with the release of Horde-3.2 and can be considered stable enough for production use. Shortly after the release of 3.2 the framework has seen some drastic structural changes that turn the framework into a developers library and further improve access to the Kolab server.

This new structure will provide the basis for Kolab Server access within Horde for the next few years.

Code repositories


The coding setup is rather complex as it needs to support different requirements:

  • It must provide a solid and stable basis for the Kolab web client offered with the Kolab server.
  • It must provide PEAR packages for the Kolab server core functions (such as the free/busy system or the resource management).
  • It must allow upstream integration of patches developed for either the Kolab web client or the PEAR packages.

To support all three wishes there are three different branches involved. All branches are maintained in git and hosted at github.

Patch management happens via topgit.

The Kolab web client branch

The Kolab web client branch is currently based on the horde-webmail-1.2.0 release. This provides a solid basis for the additional Kolab patches.

On top of that base the patches to make the final Kolab web client are being applied. The final branch representing the current Kolab web client is represented by the t/KOLAB branch. The status of the patches contained in this branch are maintained in the STATUS file in the top directory of that branch.

From time to time the whole patch series is exported to Kolab CVS so that it can be used to build the Kolab web client package there.

Experimental features not yet included in the Kolab web client are kept in the branch t/EXPERIMENTAL.

The branch for Kolab PEAR packages

The PEAR packages required for core Kolab server functionality are derived from the current Horde stable branch. This is currently kept in CVS at http://cvs.horde.org but a copy is kept on the horde-fw3 repository on github. Development takes place on github and new patches are merged into Horde CVS.

The Horde HEAD branch

This is the most complex beast of the branches as Horde is currently switching from CVS to git. For the Kolab specific Horde development this switch is represented by three different repositories on github:

  • "horde" - a copy of Horde git HEAD. This is the target repository for the next Horde version.
  • "horde-hatchery" - a copy of the Horde hatchery. This contains experimental code.
  • "horde-cvs" - a copy of the current Horde CVS HEAD which is going to be retired at some point.

This setup is complex and you should not be bothered by it if you don't want to submit patches against Horde HEAD at the moment.

Final notes

The goal is to have finally have all Kolab specific code within the Horde git repository and to have no special Kolab web client branch. Everything will be installed via clean packages then. This target should be reached with Horde 4 and has no fixed time frame yet.

Horde code



Horde authentication is implemented based on IMAP authentication. There is a special "kolab" driver for the authentication system implementing this. This driver also allows login via a shorter UID which is remapped to the users e-mail address by accessing the Kolab LDAP tree.

  • The Auth driver should be capable of handling "special" Kolab users correctly (or at least aid in helping them correctly). "Special" users are administrators, maintainers or domain-maintairs.


A special "kolab" driver exists that implements the concept of "distribution lists" stored in LDAP on the Kolab server. These Kolab Sever groups are mapped to user groups within Horde. Note: Kolab also has the concept of distribution lists that users can store in IMAP. These two should not be confused.

  • Write access for the administrator could be implemented.
  • A file based Group driver could be useful if people want to avoid LDAP usage.
  • The group driver should be cleaned up to use the new Kolab_Server module within the Horde framework.


The history driver is based on an SQL database and for Kolab an SQLite db is the recommended option.


This package provides an implementation of the Kolab format specification.

Developers might be interested in the extended package description.


This package provides read/write access to the Kolab Server user database which is stored in LDAP.

Developers might be interested in the extended package description.

  • The package currently only implements read access to the LDAP database. It should also implement write access. That would allow to convert the Kolab webadmin to use the package as a basis for the GUI.


The core system for Kolab support is mainly concerned with cached IMAP access and reading/writing the Kolab format. It also contains some other Kolab specific utilities.

  • The Kolab driver currently does not know how to handle attachments which are allowed within the Kolab format. Issue: 1989.
  • There is no collision detection at the moment. If an object is modified at the same time as another Kolab client accessed the object Horde will overwrite the values from the other client. Issue: 1986.
  • The code in this module needs to be restructured once we reach Horde 4 as there were severe structural constraints whithin Horde 3 that will fall away in the initial development phase of Horde 4
  • IMAP access should work through a single class that does not use a special PHP patch if possible.
  • The IMAP folder list might benefit from caching, too.
  • Speed optimization would be good in many places.
  • The code for logging IMAP modifications by external Kolab clients should only react to external modifications and not to modifications done by Horde internally (the current iplementation elicits two History calls for each internal change). CVS
  • Support login by non-standard users (such as the manager or domain maintainers). Bug: 6043.


The "Perms" package implements the Horde specific permission system. It can be based on a SQL database driver and for Kolab an SQLite db is the recommended option.

  • The Kolab permission system only supports ACLs on IMAP folders at the moment. These map to share permissions in Horde. But the Horde permission system has a broader concept of permissions and it would be nice if Horde with Kolab would support the full range of Horde permission settings.


The Horde user preferences have been traditionally stored in the Kolab LDAP tree. This is still the recommended version and there exists a special "kolab" driver that implements this option. There are also other options available for storing the user preferences and you can choose between SQL db, file and IMAP based approaches if you don't want to use LDAP.


The share system has a special IMAP based "kolab" driver.

  • IMAP specific code should be moved into the Kolab module.


SyncML works SQL based. For the Kolab server an SQLite db is the recommended option.


Turba is the Horde address book application.

  • Provide support for contact pictures and attachments. This depends on attachment support in the Kolab module. Issue: 1986.
  • Complete and/or fix support of distribution lists.


Kronolith is the Horde calendar application.


Nag is the Horde ToDo list manager.

  • The ID system is still broken and needs to be fixed for SyncML support.
  • Support for task recurrence in Nag would be nice.


Mnemo is the Horde note manager.

  • The ID system is still broken and needs to be fixed for SyncML support.


IMP is the Horde mail client.


Ingo is the Horde filter manager.

  • Filters are stored in the Horde preferences system. This does not completely work an requires a tiny patch. It would be better to store filters in IMAP.


Dimp is the dynamic (AJAX based) Horde mail client.


Mimp is the mobile Horde mail client.

PHP code in Kolab CVS

The newer Kolab server now uses the most recent Horde code base and a lot of the old PHP code in Kolab has been cleaned up and partially merged into the Horde::Kolab module (see above).

This provides an overview of the remaining code in Kolab CVS.


This provides the web scripts required for free/busy.

  • Could be merged into php-kolab or even Horde::Kolab


This provides the postfix filter scripts required for the Kolab server.

  • Could be merged into php-kolab or even Horde::Kolab


This special application is a modified Horde kronolith solely used for viewing free/busy information. It only exists as a special set of patches.

  • The remaining patches should be merged into Horde CVS.


This is a combined package of PHP library files containing code for the free/busy system and the postfix filters.


This provides PHP classes for kolab-filter.

  • Restructure the resource handling to use the current Horde code to reduce code duplication.
  • Merge the resource handling into the Horde::Kolab module
  • Maybe the whole package could be merge into Horde::Kolab


This provides PHP classes for kolab-freebusy.

  • Maybe the whole package could be merge into Horde::Kolab


The Kolab server web administration frontend.

  • It is hard to write PHP code that looks worse or is less maintainable. This could use some major fixing.
  • Rewrite this in Horde
Personal tools