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

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.

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.

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.

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?

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/20110118/3d17ba3e/attachment.html>