[Kolab-devel] pear.kolab.org and module thoughts

[Jeroen van Meeuwen (Kolab Systems)]

Hi there,

To consolidate some of our conversations on pear.kolab.org, I've created the 
following wiki page:

  http://wiki.kolab.org/Pear.kolab.org

Naturally, this page is a draft only and feedback from those actually literate 
in PHP is... well... compulsory.

One consideration I would like to make, and thus gain feedback on, is the 
following;

- Supposedly -what do I know-, some of the pear modules are actually Horde 
specific. As such, this, the current number of third party applications, and 
with an eye on the future, causes me to think they should be named 
'Horde_Kolab_*', so that it leaves us with plenty of room to (in the future) 
create the more generic 'Kolab_*' packages, and packages for use with plenty 
other applications (like 'Roundcube_Kolab_Format' with Roundcube specific 
bindings or handling or whatnot).

  I think this would help us in the following areas;

    0. Where the base module (e.g. Kolab_Format) handles the actual Kolab foo, 
possibly including Format version specific aspects, etc., it offers a feature-
complete, generic, versioned, stable API. This API can be used by virtually 
any application directly, but does require the application using the API to do 
certain stuff in a certain way; e.g. if application Foo consistently uses 
$_SESSION['user'], while Kolab_* requires the Kolab_*::user to be set, then 
one more very thin abstraction layer could simply make sure this actually 
happens and itself move at the speed application Foo requires, while the 
Kolab_* generic module remains clean.

    1. Maintain compatibility with series of versions of any given 
application; Horde moves at one speed, while Roundcube does at another. As 
such, changes needed for a Roundcube upgrade would get us in trouble if those 
changes prove to be incompatible with a Horde legacy version. E.g. a thin 
abstraction of Kolab_* using $App_Kolab_* can make sure horde3, horde4, 
roundcube, squirrelmail, a future Outlook Anywhere compatibility interface, Z-
Push, some mod_caldav based application, etc, etc, can all use the same base 
module without obfuscating, destabilizing or triggering a base module update 
because of one application while updating its code on behalf of another.

I hope this makes sense, but I'll give an example:

- Kolab_Cache is the generic module for handling cache (as is currently being 
developed).

- Using MongoDB as a backend would go to Kolab_Cache_MongoDB, as some 
organizations do not allow any programs not fully and completely sanctioned by 
their security officers, processes which sometimes take years to complete; 
Given as how (most likely) PostgreSQL or MySQL would be sanctioned, these 
could be plugged in as backends as well.

- Z-Push, Roundcube, Horde, OWA-compat, CalDAV, etc. can use Kolab_Cache 
directly, but if necessary, application specific layers can be put in between; 
Z-Push_Kolab_Cache, for example.

- Populating cache from a specific location / application:

  Kolab_Cyrus_Cache, Kolab_Dovecot_Cache

Either way, it's a matter of the naming convention allowing us to do all this 
without discovering, later on, we need to rename or otherwise mess around. I 
suppose it's worth thinking about it in terms of what would be extending what 
as well.

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/devel/attachments/20110117/38cc403d/attachment.html>