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
