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

[Jeroen van Meeuwen (Kolab Systems)]

Gunnar Wrobel wrote:
> Zitat von "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:
> > I suppose if a generic module is called Kolab_Cache, then it's backend
> > specific routines are either in Kolab/Cache/$tech.php or in seperate
> > Kolab_Cache_$tech modules -reasonable?
> 
> Yes. Horde packages have a tendency to implement the different drivers as
> Kolab/Cache/$tech.php within a single module. The dependencies coming
> with $tech
> are then usually marked as "optional". You can also extract
> Kolab/Cache/$tech.php
> into separate modules. Again such modules would be "optional" dependencies
> for Kolab_Cache.
> 
> I do see a small advantage for the "Kolab/Cache/$tech.php within one
> module" strategy: There is no fragmentation of the internal API over
> package boundaries.
> I would assume that the $tech's have a stable API and that Kolab_Cache has
> a stable API. But I can imagine that adding $tech+1 or fixing bugs might
> make changes on the internal interfaces between Kolab_Cache and $tech's
> necessary. Keeping that within one package should give you some more
> flexibility.
> 

Long story short, while in the beginning Kolab/Cache/ may very well be part of 
one and the same pear module, we have to allow ourselves to break out one or 
the other particular $tech.

For example, some distributions ship pgsql 8.4, others are still on 8.1. Same 
goes for mysql -even though distributions are, generally speaking, somehat in 
the same grander area of version ranges, we *MUST* maintain the ability to 
break out a $tech from the generic module so that we can address dependencies 
on the deployment platform.

Which module are we going to start out with?

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/20110119/27515dc4/attachment.html>