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

[Gunnar Wrobel]

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

> Gunnar Wrobel wrote:
>> Hi Jeroen,
>>
>
> Hi Gunnar,
>
>> Zitat von "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:
>> > I hope my statements in this light make a little more sense?
>>
>> Yes, they do. I would say we fully agree on the direction the packages
>> should take.
>>
>
> Excellent!
>
> Let's continue with the naming convention, which would impact us right from
> the beginning;
>
> 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.

>
> Here's a small culprit, continuing with Kolab_Cache as the example:
>
> I suppose then if one or the other library is $app-specific on top  
> of our more
> generic Kolab_Cache module, the name would be $app_Kolab_Cache, but, should
> $app already have it's own $app_Cache lib/module, 'Kolab' might just be the
> specific implementation of that cache, like with Kolab_Cache_MongoDB if you
> will.

Correct, with the exception of what I said above. I would assume that most
$app's will implement their backend drivers internally rather than as
extracted modules. You can check with the Roundcube devs but I would assume
they would subscribe to that view as they also implemented it this way when
accessing Kolab storage.

But of course there is no reason to avoid having two different backend drivers
$app_Cache and $app_Kolab_Cache even if the actual backend is the same.

Cheers,

Gunnar

>
> What do you think?
>
> 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