[Kolab-devel] kimap (imap library) Re: annotations patch in c-client what is the status?

[Gunnar Wrobel]

Hi Thomas,

Quoting Thomas Jarosch <thomas.jarosch at intra2net.com>:

> On Thursday, 5. November 2009 10:01:22 Gunnar Wrobel wrote:
>> ===C-client obsolete in Horde 4===
>>
>> Horde 4 has a completely new Imap_Client library. This library
>> implements IMAP access via two different access methods: Either via
>> the c-client functions within PHP or via a pure PHP implementation
>> based on the PHP socket functions (these are low-level networking
>> functions).
>>
>> As astonishing as it may seem: The pure PHP implementation seems to be
>> significantly faster than using the c-client library implemented in C.
>> The test script associated with the Imap_Client library uses 50% more
>> time when running based on c-client.
>
> Very nice! So our Kolab back end code with the ability to switch
> implementations inspired main line :)

Ah, well... I don't think so :) There were limitations within Imp that  
drove development for Imap_Client.

>
>> This does however '''not''' mean that libkimap is not interesting for
>> the IMAP connectivity of the Kolab server. It could potentially be
>> faster than the socket based implementation. Somebody would however
>> need to package libkimap in a PECL package (or directly in PHP) and
>> implement use of this backend in Imap_Client.
>
> Here comes the troublesome part (sorry Bernhard for not replying earlier):
> The library is written in C++ while PHP uses mostly C. We would need a lot
> of wrapper glue here. The new library also depends on Qt and some KDE
> libraries, this is quite a heavy dependency for a PHP module.

That is the disadvantage this new library has. As long as you are  
working within a context that uses Qt anyhow you are fine. But for all  
server environments you really want a light-weight library doing the  
IMAP access. I don't know if you can package libkimap with a  
lightweight Qt version. But if not I don't see it in the server but  
only the desktop environment.

Cheers,

Gunnar

>
> Maybe all the added wrapper glue kills the speed advantage, if any?
> Just think of the needed string conversions QString <-> PHP string type
> which are needed every time you access a message header/body etc.
>
> At least there is already a way to interface Qt/KDE libraries
> with PHP as there a Qt bindings for PHP:
> http://techbase.kde.org/Development/Languages/PHP-Qt
>
> Cheers,
> Thomas
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/devel/attachments/20091105/ef164b7d/attachment.sig>