[Kolab-devel] pear.kolab.org and module thoughts
Gunnar Wrobel
wrobel at horde.org
Wed Jan 19 16:31:33 CET 2011
Zitat von "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:
> 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?
Kolab_Format. It is the most basic one, has few dependencies, and
already a few consumers.
Concerning git.kolab.org we are all set and could import the code.
Where should issues
be reported to? And I would be happy if we could have CI from the
start as that helps
with the initial renaming/refactorings that will be necessary.
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
--
Core Developer
The Horde Project
e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org
pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de
More information about the devel
mailing list