Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:48881 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 82726 invoked from network); 21 Jun 2010 03:24:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Jun 2010 03:24:58 -0000 Authentication-Results: pb1.pair.com smtp.mail=ilia@prohost.org; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=ilia@prohost.org; sender-id=unknown Received-SPF: error (pb1.pair.com: domain prohost.org from 209.85.212.42 cause and error) X-PHP-List-Original-Sender: ilia@prohost.org X-Host-Fingerprint: 209.85.212.42 mail-vw0-f42.google.com Received: from [209.85.212.42] ([209.85.212.42:42596] helo=mail-vw0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 96/BB-15307-98BDE1C4 for ; Sun, 20 Jun 2010 23:24:58 -0400 Received: by vws16 with SMTP id 16so949278vws.29 for ; Sun, 20 Jun 2010 20:24:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.88.31 with SMTP id y31mr1640272vcl.174.1277090694950; Sun, 20 Jun 2010 20:24:54 -0700 (PDT) Received: by 10.220.70.202 with HTTP; Sun, 20 Jun 2010 20:24:54 -0700 (PDT) In-Reply-To: <4C1EDA4B.9070300@sugarcrm.com> References: <4C1EA662.1010601@sugarcrm.com> <49B64FA1-1BAA-4C88-AC9D-09E75792F05C@seancoates.com> <4C1ED20E.8050805@sugarcrm.com> <4C1EDA4B.9070300@sugarcrm.com> Date: Sun, 20 Jun 2010 23:24:54 -0400 Message-ID: To: Stas Malyshev Cc: PHP Internals Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PHP-DEV] APC in trunk From: ilia@prohost.org (Ilia Alshanetsky) The point is that it would be there for people to use, with as little effort as possible, which would be changing 1 byte inside the INI file. The issues APC is having with certain code is not specific to APC, and does happen with other open source caches. Perhaps we need to examine the validity of that code, or simply not cache the code that's affected. On Sun, Jun 20, 2010 at 11:19 PM, Stas Malyshev wrote: > Hi! > >> Even if the extension is compiled by default, we can (and probably >> should) leave apc.enabled at Off, recognizing some the things you are >> mentioning. > > I'm not sure I see the point of compiling it if it's disabled. Anyway, most > of the distributions probably would make it .so just as it happens now for > tons of other modules and would enable it in .ini. And building it from > source you almost never rely on defaults anyway if you know what you want > (which is the reason why you didn't use the binary one, I guess). So, > summarily, I don't think we should enable it by default, as for compiling it > by default, I don't think it matters too much since I don't believe defaults > matter too much there. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 >