Dropping the PHP imap patches (was: Re: Another KEP proposal: On IMAP-metadata (annotations))

[Gunnar Wrobel]

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

> Gunnar Wrobel wrote:
>> Quoting "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:
>> > just as an aside, if you'll let me:
>> >   What kind of effort would be involved to ultimately be able to drop the
>> >   uw-
>> >
>> > imap / php-imap annotations and myrights patches?
>> >
>> > I'm asking, because making uw-imap / php-imap compatible with RFCs
>> > 4314, 5257,
>> > 5464, and others currently implemented or others to be implemented Soon
>> > Enough(tm), may conclude to be way more work and of higher difficulty.
>> >
>> > Be it dropping horde3 in favor of horde4, be it modifying horde3, be it
>> > anything else, I'm open to suggestions ;-)
>>
>> I wouldn't say this has much to do with Horde at the moment. Yes, it
>> is one client using the patches but so do the Kolab free/busy system
>> and the Kolab resource management.
>
> All of which are horde* or Horde_* ;-)
>
>> Let's assume you want something quick and dirty right now ... then...
>>
>> 1) Kolab_Storage from Horde 4 is no option as all applications using
>> the module would need to be ported. This will probably happen during
>> this year anyhow but it will take some time and is not available just
>> now.
>>
>> 2) Make Kolab_Storage from Horde 3 work with Horde_Imap_Client from
>> Horde 4. Might be an option but Horde_Imap_Client has many Horde
>> dependencies that might interfere with the current Horde 3 libraries
>> we use.
>>
>> 3) Make Kolab_Storage from Horde 3 work with the Roundcube IMAP
>> library. Kolab_Storage from Horde 4 already allows that. And
>> Kolab_Storage allows for different IMAP drivers (currently
>> PEAR-Net_IMAP and PHP c-client). The Roundcube IMAP library should be
>> made into its own module then. Currently it is only available with the
>> whole application. But that shouldn't be hard.
>>
>> The last option would probably be the quickest one. However there is
>> another client on the 2.3.* line: z-push. I think that one also uses
>> the PHP c-client library.
>>
>
> It does indeed.
>
>> So all in all it is not totally easy. I would however assume that the
>> whole story gets resolved within the next year. Don't know if that is
>> an acceptable time frame to you though.
>>
>
> I recon the easiest way out of this is a pear library Net_IMAP4, not to say
> Net_IMAP could not be patched instead -if upstream will allow us to do so- to
> become fully compatible with the series of RFCs.

Yes, that would be an even quicker option. But the reason why we don't  
use PEAR-Net_IMAP for the Kolab server is the fact that it is so  
horribly slow in comparison to PHP c-client. If all IMAP operations  
take roughly three times as long - I can generate real numbers if  
required - it does not really help the applications based on this  
library. So I don't think this is an option for the default Kolab  
server.

Granted, c-client itself is slow (at least for something like PHP) -  
which is why PHP developers did all those IMAP libraries in pure PHP.  
And both Horde_Imap_Client and the Roundcube IMAP library demonstrate  
that you can in fact be as fast as the c-client libary with a pure PHP  
implementation. Yes, C might be even faster but I don't see anything  
on the horizon there.

Cheers,

Gunnar

>
> Kind regards,
>
> Jeroen van Meeuwen
>
> --
> Senior Engineer, Kolab Systems AG
>
> e: vanmeeuwen at kolabsys.com
> t: +44 144 340 9500
> m: +44 74 2516 3817
> w: http://www.kolabsys.com
>
> pgp: 9342 BF08
>
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format

-- 
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