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

[Gunnar Wrobel]

Hi Jeroen,

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

> Gunnar Wrobel wrote:
>> Quoting "Florian v. Samson" <florian.samson at bsi.bund.de>:
>> >  Still, as on the
>> >
>> > client-side, these patches supposedly will be received much more welcome
>> > upstream than those implementing a long outdated RFC-draft, which is
>> > quite incompatible to the final RFC5464.
>>
>> If it would be done *right now* we would also need to adapt the
>> c-client and PHP patch on the Kolab server as this one only supports
>> the old version. But no PHP developer that I know still wants to use
>> the c-client PHP extension and Horde 4 already moved away from it. So
>> these patches could be dropped in the long run anyway.
>>
>
> Gunnnar,
>
> 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. There is one thing similar to all  
of them: They use the Kolab_Storage module. So we would only have to  
touch that one - which was my main motivation for having such a  
central component.

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.

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.

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