# considering to remove ext/imap from master - Thread: https://externals.io/message/60331 - Original archive: https://news-web.php.net/php.internals/60331 - Started by Pierre Joye on 2012-04-27T13:49:03+00:00 - Messages: 19 - 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 --- ## #60331 — Pierre Joye — 2012-04-27T13:49:03+00:00 URL: https://externals.io/message/60331#60331 hi! Before I go with a RFC and all that, I would like to check the current feeling about killing ext/imap. The c-client project is dead since quite some time already. I do not see any viable alternative (applicable to server side usages) and it would be very hard to maintain the same APIs, given the little mess in the imap's API. There are also plenty of very good PHP implementation out there. Roundcube being my favourite, zeta components of the Zend Frameworks being two other. What are your thoughts about this drop? Links: http://incubator.apache.org/zetacomponents http://framework.zend.com/ http://roundcube.net/ Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #60332 — Stas Malyshev — 2012-04-27T17:47:29+00:00 URL: https://externals.io/message/60331#60332 · In reply to: #60331 Hi! > Before I go with a RFC and all that, I would like to check the current > feeling about killing ext/imap. The c-client project is dead since > quite some time already. I do not see any viable alternative > (applicable to server side usages) and it would be very hard to > maintain the same APIs, given the little mess in the imap's API. Whatever mess it is, tons of code is using it, and isn't going to move to Zend Framework any time soon (and roundcube is GPL which means it's unusable for many projects). So dropping it means these projects will never be able to upgrade. Now, what would such move give us? Is there any problem with imap now? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #60333 — Pierre Joye — 2012-04-27T18:21:31+00:00 URL: https://externals.io/message/60331#60333 · In reply to: #60332 hi, > Whatever mess it is, tons of code is using it, and isn't going to move > to Zend Framework any time soon (and roundcube is GPL which means it's > unusable for many projects). So dropping it means these projects will > never be able to upgrade. As I said there are many very good alternatives, BSD-like too. > Now, what would such move give us? Is there any problem with imap now? Yes, many (see the bugs DB). And c-client is as dead as msql. What does it bring to us? Less work, less worry, less issues, give a clear signal to the projects to migrate. Also keep in mind that we are talking about 2015 here as 5.4 still has it. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #60334 — Stas Malyshev — 2012-04-27T18:40:44+00:00 URL: https://externals.io/message/60331#60334 · In reply to: #60333 Hi! > As I said there are many very good alternatives, BSD-like too. Alternative means rewriting all the code. On top of framework previously not used in the project, with different APIs, different approach to IMAP, etc. This is a large piece of work, for many projects - totally unnecessary as ext/imap work for them right now. That provided the person in question actually owns the code, not just runs the app. In the latter case he has no options to upgrade at all. > Yes, many (see the bugs DB). And c-client is as dead as msql. Bug DB is full of bugs for everything, not a reason to drop imap. As for "less work", I don't see how much less work can be done on imap that is done now. If it still works for people, why remove it? I see no reason to do this. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #60335 — Pierre Joye — 2012-04-27T18:51:43+00:00 URL: https://externals.io/message/60331#60335 · In reply to: #60334 hi! > Alternative means rewriting all the code. On top of framework previously > not used in the project, with different APIs, different approach to > IMAP, etc. This is a large piece of work, for many projects - totally > unnecessary as ext/imap work for them right now. I think you over estimate the complexity to move something to a clean, maintained, user friendly API from a over complex, buggy and unmaintained extension and library (which can kill requests under certain circumstances too). > That provided the person in question actually owns the code, not just > runs the app. In the latter case he has no options to upgrade at all. Again, 2015! That's not now, not tomorrow but 2015! > > […] > > Bug DB is full of bugs for everything, not a reason to drop imap. As for > "less work", I don't see how much less work can be done on imap that is > done now. If it still works for people, why remove it? I see  no reason > to do this. if totally dead and not secure c-client is not a good reason, then I have no idea what a good reason is :), and again, we are saying: "Heh, I know you are busy like hell, but we are going to kill imap support in 2015, and some distros will maintain 5.4 for a couple of years longer too, so you should have enough time to migrate the little code taking care of imap". And why do I say "little code"? Because anyone making anything serious (except basic reading ops) with imap already migrated to alternatives or wrote its own implementation. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #60336 — Richard Lynch — 2012-04-27T19:41:16+00:00 URL: https://externals.io/message/60331#60336 · In reply to: #60335 > hi! > > On Fri, Apr 27, 2012 at 8:40 PM, Stas Malyshev > wrote: > > > […] > > I think you over estimate the complexity to move something to a clean, > maintained, user friendly API from a over complex, buggy and > unmaintained extension and library (which can kill requests under > certain circumstances too). I think you are over-estimating my bandwidth to take on such a task. :-) > > […] > > Again, 2015! That's not now, not tomorrow but 2015! I have an imap script running server-side to filter my email and knock out a whole bunch of spam that SpamAssasin doesn't catch. It's been running in a cron job since at least July 15, 2004 That's just the earliest mod-time file I can find in the directory... It's been running longer than that, actually. I set it up when Eudora was taking too long to download my email. And Eudora was free. And ad-free. So that's probably pre-2003, if I'm reading Wikipedia correctly. I add a new folder and edit the script or set up an alias and edit the script or find a new annoying pattern and edit the script... It's currently at 1065 lines of code, most of which are mailbox filtering or patterns to kill spam. It's been working fine for 8 years. I don't really care if it dies in any given run. It's going to run again in 10 minutes anyway. I dunno what 8 years time 10 minutes is, but that's an awful lot of times it worked just fine. I don't have time to change it, it's running all on an internal network at my webhost, so security is not a real concern. I'd have to plead "No" -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE --- ## #60338 — Stas Malyshev — 2012-04-27T20:17:48+00:00 URL: https://externals.io/message/60331#60338 · In reply to: #60335 Hi! > I think you over estimate the complexity to move something to a clean, > maintained, user friendly API from a over complex, buggy and > unmaintained extension and library (which can kill requests under > certain circumstances too). No I do not. It doesn't matter if it's maintained or not if the code *works*. However friendly and shiny new components are, it is new development in the application infrastructure, and believe me, I know how much that costs in dev time, qa time, support time, etc., etc. If you ever did such thing, you must know it too. > Again, 2015! That's not now, not tomorrow but 2015! 5.5 is planned to be released next year, isn't it? Users of imap will not be able to use it. I see no reason to set up both them and 5.5 for this fail. > if totally dead and not secure c-client is not a good reason, then I > have no idea what a good reason is :), and again, we are saying: "Heh, Good reason would be extension broken and nobody willing to fix it, or presence of the superior alternative with easy migration path. imap works for its users just fine, and alternatives require installing frameworks with substantially different APIs. So what? We have bugs in many extensions. It is sad that maintainers do not fix them, but so is the nature of the volonteer project. If the extension still works, I see no reason to remove it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #60341 — Nikita Popov — 2012-04-27T20:23:27+00:00 URL: https://externals.io/message/60331#60341 · In reply to: #60331 > hi! > > Before I go with a RFC and all that, I would like to check the current > feeling about killing ext/imap. The c-client project is dead since > quite some time already. I do not see any viable alternative > (applicable to server side usages) and it would be very hard to > maintain the same APIs, given the little mess in the imap's API. A question not directly related to the rest of the discussion: "Killing ext/imap" just means that it is not shipped by default anymore right? It will still be available via pecl, so people who want to use it, still can, right? Nikita --- ## #60342 — Daniel Macedo — 2012-04-27T20:23:33+00:00 URL: https://externals.io/message/60331#60342 · In reply to: #60336 Hi Richard, I've heard of a lot of people with little scripts running around, that need *really need* magic quotes enabled. (j/k) All joking aside I know that probably having something running fine for 8+ years is great. Congrats on that achievement! There are reasons to evolve things to the point where older code really can't remain compatible - obvious disclaimer: I don't use ext/imap I'm biased when it doesn't hurt me... - but I think that security or lack of maintenance might be the two crucial points that might culminate in that decision when thinking long term. That's not to say you shouldn't voice your opinions, specially when you're dependant on the ext, be it for a larger project, or for a personal geeky filter I congratulated you on earlier. But if the ext is no longer being maintained, even if working properly for the time being, there might be a point to marking it deprecated, with proper directions for alternatives/migrations. The problem is not today, or these past 8+ years it's been working wonderfully for you; but what happens when you're keeping the ext active [i.e. not deprecated], and problems come around some time from now. Since it's unmaintained, there might be a problem when there's no one wanting to fix it... You should probably find confort in also having a better code with a more robust API, even though you might be forced into touching something you havent for 8+ years (we all know how that feels like). If not, then at least consider this should be marked as deprecated (even without a due date for complete removal), just for the sake of no longer being maintained! ~ Daniel Macedo --- ## #60343 — Pierre Joye — 2012-04-27T20:25:59+00:00 URL: https://externals.io/message/60331#60343 · In reply to: #60341 hi Nikita., On Fri, Apr 27, 2012 at 10:23 PM, Nikita Popov wrote: > > > […] > > A question not directly related to the rest of the discussion: > "Killing ext/imap" just means that it is not shipped by default > anymore right? It will still be available via pecl, so people who want > to use it, still can, right? Right, and distros will release it forever too. We only say that we do not support it anymore, just like we did with sqlite (which has zero bugs and was widely used and did not have easy migration path for the databases). -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #60344 — Pierre Joye — 2012-04-27T20:36:50+00:00 URL: https://externals.io/message/60331#60344 · In reply to: #60336 hi, > I have an imap script running server-side to filter my email and knock > out a whole bunch of spam that SpamAssasin doesn't catch. Wrong tool for this task, but that's another discussion. Also as I said, if all you need is to read ,mails, it takes 5mins to do it with any of the previously libraries. They even have very nice to implement filters in a better way than what you could with ext/imap. > I don't have time to change it, it's running all on an internal > network at my webhost, so security is not a real concern. > > I'd have to plead "No" And what prevent you then to keep php 5.4 for the next 10 years as well? Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #60345 — Gustavo Lopes — 2012-04-27T20:54:22+00:00 URL: https://externals.io/message/60331#60345 · In reply to: #60331 On Fri, 27 Apr 2012 15:49:03 +0200, Pierre Joye wrote: > Before I go with a RFC and all that, I would like to check the current > feeling about killing ext/imap. The c-client project is dead since > quite some time already. I do not see any viable alternative > (applicable to server side usages) and it would be very hard to > maintain the same APIs, given the little mess in the imap's API. > > There are also plenty of very good PHP implementation out there. > Roundcube being my favourite, zeta components of the Zend Frameworks > being two other. > > What are your thoughts about this drop? Since the library is not maintained anymore, this is an obvious candidate to move to PECL -- same case as sqlite. But then PHP will be further from Zawinski's law of software envelopment, which is a cause for concern :) [1] http://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski.27s_law_of_software_envelopment -- Gustavo Lopes --- ## #60346 — Derick Rethans — 2012-04-27T21:00:28+00:00 URL: https://externals.io/message/60331#60346 · In reply to: #60341 > > > […] > > A question not directly related to the rest of the discussion: > "Killing ext/imap" just means that it is not shipped by default > anymore right? It will still be available via pecl, so people who want > to use it, still can, right? Sigh. That works for people that control their environment. It doesn't work for the pletoria of cases where you have to rely on the hosters. Most hosters would never install anything from PECL. As far as I know, ext/imap works, it's not beautiful, but it works. So no need to remove it. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #60347 — Pierre Joye — 2012-04-27T22:04:18+00:00 URL: https://externals.io/message/60331#60347 · In reply to: #60346 > Sigh. That works for people that control their environment. It doesn't > work for the pletoria of cases where you have to rely on the hosters. > Most hosters would never install anything from PECL. > > As far as I know, ext/imap works, it's not beautiful, but it works. So > no need to remove it. May I ask why you agreed to move sqlite away? That is a very close situation (well, better as sqlite library status was way better than current c-client). Not trying to troll, but trying hard to figure out your reasoning here. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #60348 — Stas Malyshev — 2012-04-28T01:15:32+00:00 URL: https://externals.io/message/60331#60348 · In reply to: #60347 Hi! > May I ask why you agreed to move sqlite away? That is a very close > situation (well, better as sqlite library status was way better than > current c-client). There's sqlite3, but nothing like this for imap. If there were another superior imap extension it would be different business. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #60350 — Lester Caine — 2012-04-28T09:25:05+00:00 URL: https://externals.io/message/60331#60350 · In reply to: #60348 Stas Malyshev wrote: > > […] > There's sqlite3, but nothing like this for imap. If there were another > superior imap extension it would be different business. That I think is exactly the point here? While imap is not being maintained, there has been no pressure to produce an alternative simply because it does a job. YES there are problems with it which nobody has stepped up to the plate to address which is the real problem, and changes to PHP do cause problems when they require work in all the extensions to maintain compatibility, but in the absence of an alternative is there any option but to leave it available. What are the alternatives to it that can be bundled into a base distribution? Is this another case where a switch to a more generally distributed model should be the way forward. ALL extensions are optional and only need to be rebuilt when there are core interface changes that require that, rather than every extension having to be recompiled with every version number change? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #60351 — Pierre Joye — 2012-04-28T09:31:03+00:00 URL: https://externals.io/message/60331#60351 · In reply to: #60348 hi, > Hi! > > > […] > > There's sqlite3, but nothing like this for imap. If there were another > superior imap extension it would be different business. There is no way to migrate sqlite databases to sqlite3 without doing it manually. So this point is totally irrelevant. Also imap will be available via pecl, no issue. Shared hosters won't update before 2016 anyway, for the 1st ones. I think we cover the main points. There are no really new possible arguments. I will write the RFC early next week and then ask for vote 2 weeks later. Thanks for your feedback. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #67571 — Ferenc Kovacs — 2013-05-28T06:07:49+00:00 URL: https://externals.io/message/60331#67571 · In reply to: #60351 > hi, > > On Sat, Apr 28, 2012 at 3:15 AM, Stas Malyshev > wrote: > > […] > > There is no way to migrate sqlite databases to sqlite3 without doing > it manually. So this point is totally irrelevant. > > Also imap will be available via pecl, no issue. Shared hosters won't > update before 2016 anyway, for the 1st ones. > > I think we cover the main points. > > There are no really new possible arguments. I will write the RFC early > next week and then ask for vote 2 weeks later. Thanks for your > feedback. > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > -- > > > > did you ever sent that mail? -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #71832 — Remi Collet — 2014-01-31T09:02:56+00:00 URL: https://externals.io/message/60331#71832 · In reply to: #60331 Le 27/04/2012 15:49, Pierre Joye a écrit : > hi! > > Before I go with a RFC and all that, I would like to check the current > feeling about killing ext/imap. The c-client project is dead since > quite some time already. I do not see any viable alternative > (applicable to server side usages) and it would be very hard to > maintain the same APIs, given the little mess in the imap's API. > > There are also plenty of very good PHP implementation out there. > Roundcube being my favourite, zeta components of the Zend Frameworks > being two other. > > What are your thoughts about this drop? FYI php-imap extension is no more available in RHEL-7 (beta) because of c-client. So I will agree a move to pecl for this extension. Remi. > Links: > http://incubator.apache.org/zetacomponents > http://framework.zend.com/ > http://roundcube.net/ > > Cheers,