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

[Jeroen van Meeuwen (Kolab Systems)]

Gunnar Wrobel wrote:
> 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.
> 

Well, I wasn't saying we need to go the patch-PEAR-Net_IMAP-upstream route, 
but if we do, speed improvements would obviously be among the deliverables.

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