Re: [PHP-DEV] considering to remove ext/imap from master
On Sat, Apr 28, 2012 at 11:31 AM, Pierre Joye pierre@gmail.com wrote: hi, On Sat, Apr 28, 2012 at 3:15 AM, Stas Malyshev smalys...@sugarcrm.com wrote: 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php did you ever sent that mail? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] considering to remove ext/imap from master
Stas Malyshev wrote: 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
hi, On Sat, Apr 28, 2012 at 3:15 AM, Stas Malyshev smalys...@sugarcrm.com wrote: 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] considering to remove ext/imap from master
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
hi, On Fri, Apr 27, 2012 at 7:47 PM, Stas Malyshev smalys...@sugarcrm.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
hi! On Fri, Apr 27, 2012 at 8:40 PM, Stas Malyshev smalys...@sugarcrm.com wrote: 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! 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
On Fri, April 27, 2012 1:51 pm, Pierre Joye wrote: hi! On Fri, Apr 27, 2012 at 8:40 PM, Stas Malyshev smalys...@sugarcrm.com wrote: 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). I think you are over-estimating my bandwidth to take on such a task. :-) 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! 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-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
On Fri, Apr 27, 2012 at 3:49 PM, Pierre Joye pierre@gmail.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
hi Nikita., On Fri, Apr 27, 2012 at 10:23 PM, Nikita Popov nikita@googlemail.com wrote: On Fri, Apr 27, 2012 at 3:49 PM, Pierre Joye pierre@gmail.com wrote: 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? 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
hi, On Fri, Apr 27, 2012 at 9:41 PM, Richard Lynch c...@l-i-e.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
On Fri, 27 Apr 2012 15:49:03 +0200, Pierre Joye pierre@gmail.com 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
On Fri, 27 Apr 2012, Nikita Popov wrote: On Fri, Apr 27, 2012 at 3:49 PM, Pierre Joye pierre@gmail.com wrote: 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? 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
On Fri, Apr 27, 2012 at 11:00 PM, Derick Rethans der...@php.net wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
