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

[Gunnar Wrobel]

Hi Jeroen,

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>:
>> > 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".
>
> I can only emphasize that, I suppose, I'm talking from a more high-level,
> bird-view perspective if you will, as opposed to line-by-line, call-by-call
> code basis -which is what you are obviously much more familiar with ;-)
>
> So, let me attempt to illustrate what I'm trying to get at, and let's see if
> I'm making any sense whatsoever;
>
> If we were to create pear.kolab.org, while pear.horde.org also distributes
> Kolab_* (not the same as Horde_Kolab_*), we end up with a mess.

I did by no means intend to distribute the same package via two  
different channels.
Once a Kolab_* package has reached sufficient quality within its git.kolab.org
repository it will *solely* be distributed via pear.kolab.org.

The horde installation will be fully based on PEAR packages with  
Horde4 anyway.
Whether a dependency originates from pear.horde.org, pear.kolab.org, or
pear.php.net does not matter to Horde.

>
> As such, the Kolab_* modules are currently entirely tied into Horde -but not
> named as such: Horde_Kolab_*.
>
> If we were to think about resolving this soft namespace conflict of sorts, we
> would come up with several options;
>
> - modify defined practices on rpm and/or apt packaging of php pear  
> modules, to
> now also include the exact channel name of the module, and make a mess of how
> the system pear command works, or,
>
> - offer any (if appropriate/needed/necessary) Horde specific layer  
> on top of a
> more generic Kolab_* module available from pear.kolab.org as Horde_Kolab_*
> from pear.horde.org.

In principle there is no such layer that would be specific to the  
Horde side of
things. Depending on the timing of the switch from pear.horde.org to
pear.kolab.org such a layer might become necessary in order to avoid  
breaking BC
on the Horde side of things. But if somehow possible I would of course like to
avoid it.

There are still a few weeks until Horde4 is stabilized and if possible  
some or all
of the Kolab_* libs can be moved before that point in time. Then I don't think
there'll be such wrappers on the Horde side.

>
> That said, the second option is *not* to say it is mandatory for Kolab_*
> modules (which are to be distributed from pear.kolab.org) to be completely
> independent on anything Horde_* as distributed through pear.horde.org. It
> would, however, be desirable for the Kolab_* modules to provide a generic API
> to the underlying Kolab semantics, such as to avoid application specific
> considerations be made in a generic module.

Sure. That underlines the idea of these modules. They might not always  
have been
at that level as converting from the original Kolab server and Horde  
code situation
into the current libraries without breaking (too much) of the  
functionality at the
same time took longer than I would have assumed when I started the process.

>
> I suppose an example would be to either return one or multiple phone numbers
> with a contact; To illustrate the point, while I hope you forgive me my
> bastardization of the language and actual module names, the following
> hypothetical scenario;
>
> - Some mobile devices only accept one phone number per contact
>
> - A given contact has 3 phone numbers (home, mobile, office)
>
> - Kolab_ZPush knows about the phones capabilities better then
> Kolab_Format::Contact() and so Kolab_Format::Contact() just returns all three
> phone numbers, and Kolab_ZPush would pop off just one.
>
> A careful consideration would need to be made on whether Kolab_Format gains a
> Contact_but_for_ZPush() method (not desirable), or extends its API with a
> $how_many call (very nice), and/or whether Kolab_ZPush itself or the
> underlying Kolab_Format is to  run in circles and attempt to keep track of
> which phonenumber exactly is the one that is supposed to be synchronized with
> the phone.

As mentioned above: Any kind of example like this one should already  
be handled
the way you describe it here. I would consider any deviation from that  
line a bug.

>
> I suppose similar considerations are to be made for Authentication and
> Authorization, for which Kolab sets (or rather 'maintains') the conditions,
> semantics, handling, management, and for which * is a consumer with,  
> possibly,
> it's own handling on top of, in addition to or instead of Kolab's.
>
> 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.

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