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 |
State ⇒ Resolved
Assigned to Gunnar Wrobel
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.
individual framework package versions, so that the applications can
simply up the version of the Kolab package that they require.
directly into the respective kolab.php drivers. Is that correct?
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
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?
New Attachment: kolab[4].php
New Attachment: kolab[3].php
New Attachment: kolab[2].php
New Attachment: contact.php
New Attachment: task[1].php
New Attachment: note[1].php
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
good way to just pear upgrade horde/Kolab, but that's probably not
going to work for most setups now.
envision an exception from our BC rule.
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
State ⇒ Feedback
CVS HEAD. But I guess Kolab support hasn't been _really_ stable in
releases... other thoughts here?
New Attachment: kolab[1].php
New Attachment: kolab.php
New Attachment: task.php
New Attachment: note.php
New Attachment: kolab_xml.phpt
belongs in Kolab/tests/kolab_xml.phpt
New Attachment: XML.php
belongs in Kolab/Kolab/XML.php
New Attachment: framework-Kolab-package.xml_new-files-20070329.patch
New Attachment: framework-Kolab-Kolab.php_deprecated-functions_20070329.patch
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
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.