# IMAP patches from kolab -- can we get these merged? - Thread: https://externals.io/message/49155 - Original archive: https://news-web.php.net/php.internals/49155 - Started by Clint Byrum on 2010-07-28T15:09:55+00:00 - Messages: 13 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #49155 — Clint Byrum — 2010-07-28T15:09:55+00:00 URL: https://externals.io/message/49155#49155 Yesterday I was talking with one of my Colleagues about the Kolab project's use of some of the newer features of IMAP, notably, annotations and myrights. It turns out Kolab ships a patched PHP to do this properly, and they've been maintaining these patches for quite some time. In fact, they're up to date with 5.3.2, as seen here: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/php/patches/php-5.3.2/ Now, the myrights patch was actually submitted as a feature request here: http://bugs.php.net/bug.php?id=43948 Which, it seems, has sat unattended for the past 2.5 years. I'm not sure if the annotations patch has ever been submitted. I'd like to get these patches into mainstream PHP so that we don't have to ship some weird patched kolab-only IMAP module in Debian and Ubuntu. In fact, I'm quite opposed to doing that at all, but this means having a broken Kolab in Debian and Ubuntu (as I understand it, Horde uses the myrights patch too). I'm just wondering what it will take to get these patches merged into PHP. Do we need to update documentation as well? Thanks very much for your time! -Clint --- ## #49164 — Hannes Magnusson — 2010-07-29T08:01:01+00:00 URL: https://externals.io/message/49155#49164 · In reply to: #49155 > I'd like to get these patches into mainstream PHP so that we don't have to > ship some weird patched kolab-only IMAP module in Debian and Ubuntu. In > fact, I'm quite opposed to doing that at all, but this means having a > broken Kolab in Debian and Ubuntu (as I understand it, Horde uses the > myrights patch too). I'm just wondering what it will take to get these > patches merged into PHP. Do we need to update documentation as well? > I can't see any reason for not committing both patches - other then resolving the 2 TODOs. The docs should be updated after committing too, as usual. -Hannes --- ## #49166 — Mikko Koppanen — 2010-07-29T08:08:33+00:00 URL: https://externals.io/message/49155#49166 · In reply to: #49164 On Thu, Jul 29, 2010 at 9:01 AM, Hannes Magnusson wrote: > > > […] Hi, I was looking at annotations patch and it seems that my c-client does not support the functionality (2007b on Debian Lenny). Do the annotations require a custom patch to c-client as well? -- Mikko Koppanen --- ## #49167 — Pierre Joye — 2010-07-29T08:15:00+00:00 URL: https://externals.io/message/49155#49167 · In reply to: #49166 hi, > On Thu, Jul 29, 2010 at 9:01 AM, Hannes Magnusson > wrote: > > […] > > Hi, > > I was looking at annotations patch and it seems that my c-client does > not support the functionality (2007b on Debian Lenny). Do the > annotations require a custom patch to c-client as well? I was not sure about that either, but the latest is 2007e and that's what I want to test against before applying this patch. I also request to upload patches in the report instead of external links or mailing lists attachment, to ease reviews and avoid confusions between the various versions. See the bug report. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #49168 — Hannes Magnusson — 2010-07-29T08:27:11+00:00 URL: https://externals.io/message/49155#49168 · In reply to: #49166 > On Thu, Jul 29, 2010 at 9:01 AM, Hannes Magnusson > wrote: > > […] > > Hi, > > I was looking at annotations patch and it seems that my c-client does > not support the functionality (2007b on Debian Lenny). Do the There is a "TODO" item in the patch (which I mentioned should be fixed :)) to check for that functionality during configure, rather then hardcode it enabled :) -Hannes --- ## #49173 — Clint Byrum — 2010-07-29T17:33:39+00:00 URL: https://externals.io/message/49155#49173 · In reply to: #49155 Thanks everyone for having a look at this. I'll track the status in the bug from here on. > Yesterday I was talking with one of my Colleagues about the Kolab > project's use of some of the newer features of IMAP, notably, annotations > and myrights. > > It turns out Kolab ships a patched PHP to do this properly, and they've > been maintaining these patches for quite some time. In fact, they're up > to date with 5.3.2, as seen here: > > http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/php/patches/php-5.3.2/ > > Now, the myrights patch was actually submitted as a feature request here: > > http://bugs.php.net/bug.php?id=43948 > > Which, it seems, has sat unattended for the past 2.5 years. I'm not sure > if the annotations patch has ever been submitted. > > I'd like to get these patches into mainstream PHP so that we don't have to > ship some weird patched kolab-only IMAP module in Debian and Ubuntu. In > fact, I'm quite opposed to doing that at all, but this means having a > broken Kolab in Debian and Ubuntu (as I understand it, Horde uses the > myrights patch too). I'm just wondering what it will take to get these > patches merged into PHP. Do we need to update documentation as well? > > Thanks very much for your time! > > -Clint --- ## #49176 — Raphael Geissert — 2010-07-29T21:44:58+00:00 URL: https://externals.io/message/49155#49176 · In reply to: #49166 Mikko Koppanen wrote: > I was looking at annotations patch and it seems that my c-client does > not support the functionality (2007b on Debian Lenny). Do the > annotations require a custom patch to c-client as well? The request to include the annotations patch at Debian is at: http://bugs.debian.org/456947 But as you can see, it is marked as blocked by http://bugs.debian.org/456591 (the request against uw-imap/libc-client to include the patch.) Therefore, the blocker at the php level is enabling the annotations code at configure time if the system supports it. Of course, support on libc-client is necessary for it to be of any use. I just talked to Jonas Smedegaard (the Debian maintainer of libc-client,) and apparently the reason for not merging it is that the code is dead upstream and unmaintainable. A dead end. While digging for alternatives, it appears that there was a discussion in 2004 for FC2 about the situation of libc-client, but besides that: nothing. As it seems, the best and maintainable solution is to switch to some other alternative library (sadly, there's no such candidate atm.) HTH -- Raphael Geissert --- ## #49182 — Raphael Geissert — 2010-07-30T04:38:02+00:00 URL: https://externals.io/message/49155#49182 · In reply to: #49176 Raphael Geissert wrote: > As it seems, the best and maintainable solution is to switch to some other > alternative library (sadly, there's no such candidate atm.) Actually, I wonder if the imap extension shouldn't be dropped altogether in trunk. The libraries written in PHP are actually more reliable and work better. Regards, -- Raphael Geissert --- ## #49185 — Pierre Joye — 2010-07-30T14:13:12+00:00 URL: https://externals.io/message/49155#49185 · In reply to: #49176 hi, > Mikko Koppanen wrote: > > […] > > The request to include the annotations patch at Debian is at: > http://bugs.debian.org/456947 > > But as you can see, it is marked as blocked by > http://bugs.debian.org/456591 > > (the request against uw-imap/libc-client to include the patch.) > > Therefore, the blocker at the php level is enabling the annotations code at > configure time if the system supports it. Of course, support on libc-client > is necessary for it to be of any use. > > I just talked to Jonas Smedegaard (the Debian maintainer of libc-client,) > and apparently the reason for not merging it is that the code is dead > upstream and unmaintainable. A dead end. While digging for alternatives, it > appears that there was a discussion in 2004 for FC2 about the situation of > libc-client, but besides that: nothing. I don't see a problem to include that in PHP as long as it is well done. Mikko updated the patches nicely, both the php and the c-client patch. > As it seems, the best and maintainable solution is to switch to some other > alternative library (sadly, there's no such candidate atm.) What make you think that c-client is dead? I have seen updates last year and I know that the main developer still works and support this library. I don't think either that using 6 years old discussions to decide something is a good idea. Something like that happened for php and gd with Etch, and it was a total fiasco. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #49187 — Tomas Kuliavas — 2010-07-30T15:56:11+00:00 URL: https://externals.io/message/49155#49187 · In reply to: #49185 2010.07.30 17:13 Pierre Joye rašė: > What make you think that c-client is dead? I have seen updates last > year and I know that the main developer still works and support this > library. IMHO main developer works on Panda IMAP. Source code is not publicly available (http://panda.com/imap/FAQ.html#panda). Last UW IMAP release was in 2008-12-17 and UW fired their IMAP developer team (Crispin's email is somewhere on IMAP mailing list, can't find link right now). http://panda.com/imap/ states that they don't support UW IMAP. UW IMAP and c-client might offer reference IMAP implementation, but you should ask sane packager or server admin what they think about package configuration options. Or lack of any supported configuration files. -- Tomas --- ## #49188 — Pierre Joye — 2010-07-30T16:03:11+00:00 URL: https://externals.io/message/49155#49188 · In reply to: #49187 On Fri, Jul 30, 2010 at 5:56 PM, Tomas Kuliavas wrote: > UW IMAP and c-client might offer reference IMAP implementation, but you > should ask sane packager or server admin what they think about package > configuration options. Or lack of any supported configuration files. I did not say something about the quality but only about availability/support. But we agree on one thing, there is a cruel need for good imap library. etpan works well for desktop but does not fit well for web (referring to the conclusion of the developer of the php binding in pecl). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #49189 — Raphael Geissert — 2010-07-30T18:11:06+00:00 URL: https://externals.io/message/49155#49189 · In reply to: #49185 Pierre Joye wrote: > On Thu, Jul 29, 2010 at 11:44 PM, Raphael Geissert > wrote: > > […] > > What make you think that c-client is dead? I have seen updates last > year and I know that the main developer still works and support this > library. I don't think either that using 6 years old discussions to > decide something is a good idea. Tomas already clarified that point. > Something like that happened for php > and gd with Etch, and it was a total fiasco. I talked to Jonas about gd too, the failed collaboration attempt, etc, and I would like if we could try to make it work. However, that's a different topic and should be discussed separately. I hope we can count on you. Cheers, -- Raphael Geissert --- ## #49190 — Pierre Joye — 2010-07-30T21:13:33+00:00 URL: https://externals.io/message/49155#49190 · In reply to: #49189 > Pierre Joye wrote: > > […] > > Tomas already clarified that point. There is nothing clarified here. Yes, the c-client is closed to death but I don't see anything close to it out there, from a C/C++ point of view (with a usable license, there are some good libs under gpl, sadly). And yes, there are very good user land implementation out there as well. Does it mean that we should give up on having imap support in core? I don't think so :). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org