6.0.0-beta1
8/9/25

[#5175] Restructuring the Kolab driver
Summary Restructuring the Kolab driver
Queue Horde Framework Packages
Queue Version HEAD
Type Enhancement
State Resolved
Priority 1. Low
Owners wrobel (at) horde (dot) org
Requester wrobel (at) pardus (dot) de
Created 03/28/2007 (6709 days ago)
Due
Updated 05/25/2007 (6651 days ago)
Assigned 05/07/2007 (6669 days ago)
Resolved 05/25/2007 (6651 days ago)
Milestone
Patch No

History
05/25/2007 02:24:03 PM Gunnar Wrobel Comment #26
State ⇒ Resolved
Reply to this comment
In CVS.
05/07/2007 06:00:56 PM Gunnar Wrobel State ⇒ Assigned
 
04/18/2007 03:44:39 PM Gunnar Wrobel Comment #25
Assigned to Gunnar Wrobel
Reply to this comment
We continued discussion on this and it seems the best solution is to 
keep the structure as suggested by the current patches.



We will have to define one interface that has to be kept stable 
anyhow. Either this will be on the level of the array that is being 
transferred between the specific Kolab XML handler (e.g. note.php or 
task.php) and the application. Or it is on the level of the XML.php 
handler that would be used within each application.



There are two reasons why the first solution might be better: The XML 
handling resides fully within the Kolab module. Thus it is also 
available to other PHP applications that would use the Horde Framework 
modules as a library. In addition the XML.php interface would be 
binding for all four applications we are currently targeting. 
Specifying the transferred array is something we do per application.



Since it is important to get the interface right the first time we 
commit it, we will still wait with this until the kronolith Kolab 
driver has also been converted to the new structure.


04/11/2007 05:17:07 PM Chuck Hagenbuch Comment #24 Reply to this comment
Ideally for 4.0, we'll finally separate the horde version from 
individual framework package versions, so that the applications can 
simply up the version of the Kolab package that they require.
04/11/2007 12:21:21 PM thomas (dot) jarosch (at) intra2net (dot) com Comment #23 Reply to this comment
Hello Chuck,
Anyhow I assume the better solution would be to put the note.php part
directly into the respective kolab.php drivers. Is that correct?
That sounds right to me, yes.
Ok. Let's assume we need some major changes in XML.php, how would that 
be done? Only with Horde 4.0? I can imagine once the new Kolab code is 
in place and put into production the first time, the need for changes 
will arise or at least we should have the possibility to do so. Though 
I hope the code is bug free ;-)



Cheers,

Thomas


04/09/2007 09:32:19 PM Chuck Hagenbuch Comment #22 Reply to this comment

[Show Quoted Text - 12 lines]
That sounds right to me, yes.
04/04/2007 09:32:28 PM wrobel (at) pardus (dot) de Comment #21 Reply to this comment
Hm, I believe the currently suggested organization would actually 
introduce a structural problem.



The XML drivers are strongly coupled to the respective kolab.php 
drivers within the different applications (note.php with mnemo, 
task.php with nag, etc.) Once we would later change something within 
note.php we might also need to adapt the mnemo kolab driver. While 
this would probably not happen very often, I assume we would break 
backward compatibility in that case.



I simply did not think about this before - still not deep enough in 
the Horde structure, but I'm trying to improve :)



Anyhow I assume the better solution would be to put the note.php part 
directly into the respective kolab.php drivers. Is that correct?
04/03/2007 07:24:23 AM wrobel (at) pardus (dot) de Comment #20
New Attachment: kolab[4].php Download
Reply to this comment
New Kolab driver for turba
04/03/2007 07:23:50 AM wrobel (at) pardus (dot) de Comment #19
New Attachment: kolab[3].php Download
Reply to this comment
New Kolab driver for nag
04/03/2007 07:23:04 AM wrobel (at) pardus (dot) de Comment #18
New Attachment: kolab[2].php Download
Reply to this comment
New Kolb driver for mnemo
04/03/2007 07:22:27 AM wrobel (at) pardus (dot) de Comment #17
New Attachment: contact.php Download
Reply to this comment
XML driver for contacts
04/03/2007 07:21:56 AM wrobel (at) pardus (dot) de Comment #16
New Attachment: task[1].php Download
Reply to this comment
XML driver for tasks
04/03/2007 07:21:27 AM wrobel (at) pardus (dot) de Comment #15
New Attachment: note[1].php Download
Reply to this comment
Thomas Jarosch prepared the Turba driver and I fixed some issues on 
the nag driver. In addition I moved some data processing to the XML 
drivers so that this effort happens before caching the data.



XML driver for notes
03/29/2007 03:25:17 PM Chuck Hagenbuch Comment #14 Reply to this comment
I'm mostly okay with a BC break; it'd be even better if there was a 
good way to just pear upgrade horde/Kolab, but that's probably not 
going to work for most setups now.
03/29/2007 09:29:29 AM Jan Schneider Comment #13 Reply to this comment
I would say that 2) would be the most elegant solution. But I can also 
envision an exception from our BC rule.
03/29/2007 06:15:23 AM wrobel (at) pardus (dot) de Comment #12 Reply to this comment
Lack of stability of the older driver was the reason for choosing this 
solution. If you feel that is not ok I think there are two possible 
alternatives:



  1) adding this as a second possible Kolab driver (as kolab2.php)



or



  2) having the old and the new driver in the kolab.php class with a 
wrapper that decides automatically based on the capabilities of the 
Kolab module
03/28/2007 11:43:06 PM Chuck Hagenbuch Comment #11
State ⇒ Feedback
Reply to this comment
I'm not sure I like the bc break of just dieing if people aren't using 
CVS HEAD. But I guess Kolab support hasn't been _really_ stable in 
releases... other thoughts here?
03/28/2007 11:17:16 PM wrobel (at) pardus (dot) de Comment #10 Reply to this comment
Turba and Kronolith have not yet been transferred to the new framework.
03/28/2007 11:16:26 PM wrobel (at) pardus (dot) de Comment #9
New Attachment: kolab[1].php Download
Reply to this comment
A new Kolab driver for nag that uses the new framework.
03/28/2007 11:15:08 PM wrobel (at) pardus (dot) de Comment #8
New Attachment: kolab.php Download
Reply to this comment
A new Kolab driver for mnemo that uses the new framework.
03/28/2007 11:14:03 PM wrobel (at) pardus (dot) de Comment #7
New Attachment: task.php Download
Reply to this comment
This defines the XML format for tasks and belongs in Kolab/Kolab/XML/task.php
03/28/2007 11:13:27 PM wrobel (at) pardus (dot) de Comment #6
New Attachment: note.php Download
Reply to this comment
This defines the XML format for notes and belongs in Kolab/Kolab/XML/note.php
03/28/2007 11:12:39 PM wrobel (at) pardus (dot) de Comment #5
New Attachment: kolab_xml.phpt Download
Reply to this comment
The XML-class lends itself to unit testing. This is a test script that 
belongs in  Kolab/tests/kolab_xml.phpt
03/28/2007 11:11:11 PM wrobel (at) pardus (dot) de Comment #4
New Attachment: XML.php Download
Reply to this comment
The main XML-Wrapper that now does all of the XML handling. This 
belongs in Kolab/Kolab/XML.php
03/28/2007 11:09:56 PM wrobel (at) pardus (dot) de Comment #3
New Attachment: framework-Kolab-package.xml_new-files-20070329.patch Download
Reply to this comment
Some files will get added to the package.
03/28/2007 11:09:18 PM wrobel (at) pardus (dot) de Comment #2
New Attachment: framework-Kolab-Kolab.php_deprecated-functions_20070329.patch Download
Reply to this comment
This marks some functions in the global Kolab driver as deprecated.
03/28/2007 11:08:20 PM wrobel (at) pardus (dot) de Comment #1
State ⇒ New
Priority ⇒ 1. Low
Type ⇒ Enhancement
Summary ⇒ Restructuring the Kolab driver
Queue ⇒ Horde Framework Packages
New Attachment: framework-Kolab-Kolab-IMAP.php_New-framework_20070329.patch Download
Reply to this comment
Currently each Kolab driver in the different applications needs to 
know a lot about the XML format used for storing groupware objects 
like notes, tasks etc. on the groupware server.



This makes it hard if not impossible to cache the data on the way from 
the IMAP storage to the groupware application. On the other hand 
caching is necessary to allow Horde to work on a Kolab server that 
stores several thousand groupware objects.



The attached patches and files implement a new framework that 
restructure the Kolab driver so that each application driver only 
needs to transfer data as a hash. This hash can also be cached by the 
main Kolab module.



The patches will not destroy the old functionality of the Kolab driver 
and only add the new framework to the classes.



I am going to attach all parts of this patch to this bug, but please 
tell me if I should try to seperate this to a larger degree.

Saved Queries