Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:60338 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 47441 invoked from network); 27 Apr 2012 20:17:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Apr 2012 20:17:52 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.203 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.203 smtp203.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.203] ([67.192.241.203:41628] helo=smtp203.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B9/65-16466-FEEFA9F4 for ; Fri, 27 Apr 2012 16:17:52 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp20.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 9EF752581B9; Fri, 27 Apr 2012 16:17:49 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp20.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 3B4122581B0; Fri, 27 Apr 2012 16:17:49 -0400 (EDT) Message-ID: <4F9AFEEC.5080902@sugarcrm.com> Date: Fri, 27 Apr 2012 13:17:48 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Pierre Joye CC: PHP internals References: <4F9ADBB1.1040006@sugarcrm.com> <4F9AE82C.8080006@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] considering to remove ext/imap from master From: smalyshev@sugarcrm.com (Stas Malyshev) 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