Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:48884 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 87019 invoked from network); 21 Jun 2010 03:39:36 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Jun 2010 03:39:36 -0000 Authentication-Results: pb1.pair.com header.from=ilia@prohost.org; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=ilia@prohost.org; spf=permerror; 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:44162] helo=mail-vw0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 86/9C-15307-6FEDE1C4 for ; Sun, 20 Jun 2010 23:39:35 -0400 Received: by vws16 with SMTP id 16so962873vws.29 for ; Sun, 20 Jun 2010 20:39:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.63.207 with SMTP id c15mr1702594vci.225.1277091570727; Sun, 20 Jun 2010 20:39:30 -0700 (PDT) Received: by 10.220.70.202 with HTTP; Sun, 20 Jun 2010 20:39:30 -0700 (PDT) In-Reply-To: <4C1EDCFE.307@sugarcrm.com> References: <4C1EA662.1010601@sugarcrm.com> <49B64FA1-1BAA-4C88-AC9D-09E75792F05C@seancoates.com> <4C1ED20E.8050805@sugarcrm.com> <4C1EDA4B.9070300@sugarcrm.com> <4C1EDCFE.307@sugarcrm.com> Date: Sun, 20 Jun 2010 23:39:30 -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) Stas, If there is a better alternative to APC we can bundle with PHP, I am definitely open to exploring that idea. However the alternatives I am familiar either are closed source or have licences incompatible with PHP, and that's without getting into the "better" argument. On Sun, Jun 20, 2010 at 11:31 PM, Stas Malyshev wrote: > Hi! > >> 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 > > We don't discuss putting other OSS (or non-OSS for that matter :) caches in > any PHP build, enabled by default, do we? That's the point. > And really, enabling extension - either in source build or in binary build - > is not that hard. If they are able to write PHP, they should be able to > remove ; before extension= or write --enable-apc. > >> examine the validity of that code, or simply not cache the code that's >> affected. > > I'd rather not make such kludges, especially if we talk about main PHP > source. It's not a good road to take. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 >