Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:60334 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 33860 invoked from network); 27 Apr 2012 18:40:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Apr 2012 18:40:50 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.153 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.153 smtp153.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.153] ([67.192.241.153:43947] helo=smtp153.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AF/D2-16466-038EA9F4 for ; Fri, 27 Apr 2012 14:40:49 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp25.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id A5CB22D074D; Fri, 27 Apr 2012 14:40:45 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp25.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 45ACA2D05A8; Fri, 27 Apr 2012 14:40:45 -0400 (EDT) Message-ID: <4F9AE82C.8080006@sugarcrm.com> Date: Fri, 27 Apr 2012 11:40:44 -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> 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! > 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