Dropping the PHP imap patches (was: Re: Another KEP proposal: On IMAP-metadata (annotations))
Gunnar Wrobel
wrobel at horde.org
Fri Jul 15 11:57:24 CEST 2011
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
More information about the format
mailing list