[Kolab-devel] web groupware

[Gunnar Wrobel]

Hi Thomas,

>>  1) Splitting the current Kolab driver into a "Base driver", an "IMAP
>>     Storage driver" and a "XML groupware object driver". This first
>>     step will only provide a solution that allows to continue using
>>     the current structure but that can be deprecated later.
>>
>>  2) Rework the "Base driver" to accept groupware object data as a
>>     hash. Adapt the "IMAP Storage driver" to this change.
>>
>>  3) Create four XML groupware drivers that specifically handle tasks,
>>     events, addresses and notes.
>>
>>  4) Rework the Kolab drivers of mnemo, kronolith, nag, and turba to
>>     work with the new hash based scheme instead of manipulating XML
>>     directly.
>
> Thanks for your review. As you pointed out, currently all drivers are closely 
> tied to the low-level XML functions. Splitting this up is very messy and IMHO 
> doubles the work to be done. If you execute steps 1. to 3., you'll get close 
> to the current state of the caching driver. 

Right. The main reason why I would like to split this into distinct
steps and merge it slowly into Horde is to maintain backward
compatibility. The stepwise approach allows to change the structure
without disturbing current functionality. The new features would then
be added on top of the new structure. This would allow to later port
each of the four groupware applications separately to the new
system. At the same time it will not be necessary to worry about an
older Turba, Kronolith, Mnemo etc. working together with the newer
library.

I hope that approach will not be too messy. It would certainly leave a
certain amount of code in the driver that will be marked "deprecated"
but I believe that should still be acceptable.

This first restructuring should not take too much time and once it is
done I can check with the Horde devs to see if they accept the new
structure or if it needs to be improved.

> If we theoretically disable writing the cache to the disk, the
> caching driver should behave exactly the same to the user.

Yes, I want to be able to have different drivers and it should be
possible to disable the driver. Your current driver accesses the hard
disk directly and I currently don't know if that would be okay with
the Horde project. It might be necessary to adapt to the virtual file
storage system or something similar.

> Also I'm not sure if the additional abstraction layer between the "base 
> driver" and "IMAP storage driver" won't make things avoidable complex. 
> How would that layer look like?

It would mainly consist of the functionality currently provided by the
Kolab class within the Kolab.php driver. But it would delegate all
functionality dealing with storage in IMAP to the specific storage
driver. It would be somewhat similar to the newer Share driver that
also has different storage back ends.

I believe one would end up with three to four different storage
drivers for Kolab:

 - a basic one that enables "old style" handling of groupware objects.
 - a plain IMAP storage driver
 - a cached IMAP storage driver
 - (a cached IMAP storage driver that uses VFS)

The Kolab class would then select the configured back end and delegate
the calls there.

> Do you like the concept of splitting the big Kolab.php file into several 
> Kolab/xyz.php files like I did with the caching driver? The idea behind that 
> was to improve maintainability of the code.

Absolutely. This is how Horde does it for most of the modules and so I
believe we should definitely stick to splitting the scripts into
manageable parts wherever useful.

Cheers,

Gunnar

-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

    >> Mail at ease - Rent a kolab groupware server at p at rdus <<

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium