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

[Gunnar Wrobel]

Hi Jeroen,

Zitat von "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:

> 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.

I'm tempted to disagree. It depends on what you define as "Horde  
specific". For the Horde3 variants I must agree that the Kolab_*  
libraries contain parts that embed it strongly into the Horde code  
base. To such an extend that it is sometimes hard to use it outside of  
that context.

Anyway: when it comes to pear.kolab.org I believe it only makes sense  
to speak about the current Horde4 version of the libraries.

These newer versions are fully intended to be used outside of a  
standard Horde installation. A "standard Horde installation" refers to  
the full application stack however. I'm not saying that it makes sense  
to slim down the Kolab_* to such an extent that they do not rely on  
*any* other Horde code. For the very simple ones (e.g. Kolab_Format)  
that might even work.

But if I look at things like Kolab_FreeBusy which are already  
applications themselves then I must say I see no reason why it should  
not rely on other Horde *libraries*. It makes no sense to code our own  
recurrence calculations if there is the "Date" package from Horde  
available. Or the "iCalendar" package for all things iCal, vCard and  
so on. Of course it makes sense to switch if something better comes  
along. But for now I'm convinced that we should stick with those  
dependencies.

For Horde4 I'm able to guarantee that these libraries will be packaged  
in a sane way. In Horde3 they were only available as a part of the  
"horde" base package. For Horde4 they will see their own releases via  
pear.horde.org.

Given all that I would say the current Kolab_* Horde4 are in no way  
"Horde specific" anymore. Well, part of them still need to be adapted  
to Horde4 but a good part of the process is completed.

> 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.

Make sense in general but I would say this is already possible now.  
Any overlay on top of the current packages should be easy.

>
>     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.

Makes sense to me and will hopefully develop like that over time.

Cheers,

Gunnar

>
> 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
>



--
Gunnar Wrobel
Developer, Kolab Systems AG

e: wrobel at kolabsys.com
t: +49 700 6245 0000
w: http://www.kolabsys.com

pgp: 9703 43BE

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.