Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:66357 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 86091 invoked from network); 28 Feb 2013 20:13:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Feb 2013 20:13:07 -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.113 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.113 smtp113.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.113] ([67.192.241.113:47668] helo=smtp113.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1D/4C-25879-25ABF215 for ; Thu, 28 Feb 2013 15:13:07 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp21.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 45E4D2409C2; Thu, 28 Feb 2013 15:13:04 -0500 (EST) X-Virus-Scanned: OK Received: by smtp21.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id F09422402D1; Thu, 28 Feb 2013 15:13:03 -0500 (EST) Message-ID: <512FBA50.4000308@sugarcrm.com> Date: Thu, 28 Feb 2013 12:13:04 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Anthony Ferrara CC: "internals@lists.php.net" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Include XDebug and Suhosin Patch in Core for 5.5 From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > Based off of the recent discussion around pulling in ZO+ into core, I've > come to the conclusion that we should also pull in XDebug and Suhosin into > core at the same time. Suhosin has multiple BC-incompatible and performance-problematic changes and limits and the author refused many times to work with PHP team. I'm not sure how we could pull extension that the author of it isn't interested in working with PHP group. > 1. It has integration issues with ZO+ in that it has to be included in a > specific order (specifically around ini declarations). If it was included > into core, this could be accounted for allowing for more robust behavior. I'm not sure what you mean about ini declarations, could you expand on this or refer me to the place where it is explained? > 2. Both to be maintained for each new language feature as well as > opcode-caches. This will have the same benefit as integrating ZO+, as it > can be maintained inline with the engine. I'm not sure how it's different than any other extension. If API changes, they need to change for every version. Also, are you sure either of the maintainers actually wants to be part of PHP release cycle? At least for Suhosin we know it's actually not the case. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227