Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:47970 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 62527 invoked from network); 15 Apr 2010 11:12:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Apr 2010 11:12:08 -0000 Authentication-Results: pb1.pair.com header.from=tyra3l@gmail.com; sender-id=pass; domainkeys=bad Authentication-Results: pb1.pair.com smtp.mail=tyra3l@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.219 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: tyra3l@gmail.com X-Host-Fingerprint: 209.85.218.219 mail-bw0-f219.google.com Received: from [209.85.218.219] ([209.85.218.219:33841] helo=mail-bw0-f219.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8F/5D-20494-784F6CB4 for ; Thu, 15 Apr 2010 07:12:07 -0400 Received: by bwz19 with SMTP id 19so17948bwz.1 for ; Thu, 15 Apr 2010 04:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=r3kXDKifHAjT5+m/wIZLJNRcZoYXreonnGBqcddk+ew=; b=B4FMSI8yG8Gt5eYx8byHfCcciyFKSHwrDjEiTvuCEEs5Gv2gIrgbXGgMZPPtHBVWzl CoYjcKcg56rM7RF3LFMaOktcjhyGmWHo6IUuDYcL21RPZNzCEQlJbPYvk3tO+S7x6qUQ 5gtaGEwkluWdZ2Q4M5PQuV9b/oW+IqXv3ywyQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Nl1TDLzITgu5K++2qPDtes6CwKd7JsP7koOdnBk3hlAFyV7PrMB94q08pkwSKsUXQS F/Qp/FSYn8cpIYejgz1N+4F6PFpWRtJdNpTkYe9INxpvX8lRLzkiKyAlbW9Zz/n86zaz o36yZ9N8ZkNGv7gVD0KdK3xwR8ZYLD8yRE0h8= MIME-Version: 1.0 Received: by 10.204.123.20 with HTTP; Thu, 15 Apr 2010 04:12:03 -0700 (PDT) In-Reply-To: References: <3bea96c41003301008va8ea1cbif8c16be11451eaf8@mail.gmail.com> <4BC4B553.3020807@oracle.com> <4BC4BBF9.4000903@oracle.com> <7.0.1.0.2.20100413215139.0dbcfdd8@zend.com> Date: Thu, 15 Apr 2010 13:12:03 +0200 Received: by 10.204.153.205 with SMTP id l13mr1937418bkw.95.1271329923334; Thu, 15 Apr 2010 04:12:03 -0700 (PDT) Message-ID: To: Derick Rethans Cc: Zeev Suraski , Christopher Jones , =?UTF-8?B?SsOpcsO0bWUgTG95ZXQ=?= , php-dev Content-Type: multipart/alternative; boundary=0015175cd2f679339004844490d7 Subject: Re: [PHP-DEV] [RFC] FPM INI syntax From: tyra3l@gmail.com (Ferenc Kovacs) --0015175cd2f679339004844490d7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2010/4/15 Derick Rethans > On Tue, 13 Apr 2010, Zeev Suraski wrote: > > > At 21:46 13/04/2010, Christopher Jones wrote: > > > > > J=C3=A9r=C3=B4me Loyet wrote: > > > > Le 13 avril 2010 20:17, Christopher Jones > > > > a =C3=A9crit : > > > > > > > > > > J=C3=A9r=C3=B4me Loyet wrote: > > > > > > > > > > > > As dreamcast4 advises me in the previous FPM conversation, I > > > > > > just wrote the RFC for the FPM INI syntax. > > > > > > > > > > > > It can be read here: http://wiki.php.net/rfc/fpm/ini_syntax > > > > > > > > > > > > Tell me what you think. > > > > > > > > > > > I think the RFC should clearly state what is new generic php.ini > > > > > functionality (e.g. include) and what is specific for FPM. > > > > > > > > for me everything is specific to FPM > > > > > > How is "include" specific to FPM? > > > > What he means is that it'll be implemented in the custom code > > responsible for parsing fpm.ini, and not in the ZE .ini parser which > > would be the layer below it. > > Uh, so what you're saying is that you want to use INI syntax for FPM so > that it is inline with php's INI sytanx, but then modify it with extra > statements so that it isn't the same anymore=E2=80=94not only with includ= e, but > section headers are totally ignored in php.ini as well. This whole new > INI thing is making less and less sense. The XML format like we have now > is much easier, self documented, doesn't create two different ini > formats and generally just works well. I'd be a big -1 on this special > FPM-specific INI syntax. > > Derick > > Agree, I thought that the include part will be handled from the application= . I mean you parse the global config, read the include param, and read each o= f the matching ini for merging them to the original config format. Tyrael --0015175cd2f679339004844490d7--