Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:47986 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 30686 invoked from network); 15 Apr 2010 16:44:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Apr 2010 16:44:08 -0000 Authentication-Results: pb1.pair.com smtp.mail=jerome@loyet.net; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=jerome@loyet.net; sender-id=unknown Received-SPF: error (pb1.pair.com: domain loyet.net from 209.85.218.219 cause and error) X-PHP-List-Original-Sender: jerome@loyet.net X-Host-Fingerprint: 209.85.218.219 mail-bw0-f219.google.com Received: from [209.85.218.219] ([209.85.218.219:51623] helo=mail-bw0-f219.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 99/C7-22079-65247CB4 for ; Thu, 15 Apr 2010 12:44:07 -0400 Received: by bwz19 with SMTP id 19so20665bwz.1 for ; Thu, 15 Apr 2010 09:44:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.135.83 with HTTP; Thu, 15 Apr 2010 09:44:03 -0700 (PDT) In-Reply-To: <7.0.1.0.2.20100415171003.15224c80@zend.com> References: <3bea96c41003301008va8ea1cbif8c16be11451eaf8@mail.gmail.com> <4BC4BBF9.4000903@oracle.com> <7.0.1.0.2.20100413215139.0dbcfdd8@zend.com> <7.0.1.0.2.20100415140350.0e2a5290@zend.com> <7.0.1.0.2.20100415141933.0e2a53d8@zend.com> <7.0.1.0.2.20100415143309.0e2a5a40@zend.com> <7.0.1.0.2.20100415171003.15224c80@zend.com> Date: Thu, 15 Apr 2010 18:44:03 +0200 Received: by 10.239.142.211 with SMTP id h19mr35733hba.164.1271349843801; Thu, 15 Apr 2010 09:44:03 -0700 (PDT) Message-ID: To: Zeev Suraski Cc: Ferenc Kovacs , internals@lists.php.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [RFC] FPM INI syntax From: jerome@loyet.net (=?ISO-8859-1?B?Suly9G1lIExveWV0?=) 2010/4/15 Zeev Suraski : > At 17:00 15/04/2010, Ferenc Kovacs wrote: > > >> On Thu, Apr 15, 2010 at 1:38 PM, Zeev Suraski >> <zeev@zend.com> wrote: >> At 14:30 15/04/2010, Ferenc Kovacs wrote: >> Yep, this what I'm trying to say. I thought that the include parameter i= n >> the global.ini is just a normal config variabla, which isn't interpreted= by >> the php parse ini method, only just tells the fpm, to include that files >> manualy and merge the contents of that files into the original configura= tion >> parsed from the global.ini. >> But as far as I understand the patch and the discussion, it seems that >> Jerome proposed to change the internal working of the ini parsing, to ad= d >> general support for includes. >> >> >> Actually as far as I understand what you wrote in the 1st paragraph is >> exactly what was planned. =C2 There weren't any plans to touch the .ini = parser >> itself in any way. >> >> >> - the include directive is not yet implemented because the >> zend_ini_parser is not able to handle recursive calls (because of the >> the state env which is global) >> >> This seems to like that Jerome is implying to change the zend_ini_parser >> to support includes. > > Not quite - he only wants to make the parser reentrant, so that it would = be > possible to implement include in a certain way. =A0It doesn't mean the pa= rser > itself will support include. =A0BTW - I think there are other ways to > implement include that don't require making the ini parser reentrant but > that's a different story. > >> If the includes are done by the fpm config loader/parser, then I don't >> understand why should the zend_ini_parser to be changed except the one c= ase >> that Jerome wants to implement a general include support for the ini par= ser. > > In Jerome's approach the include logic will still be at the fpm config > loader/parser level, but he's modifying the ZE ini parser slightly to mak= e > it easier for him to implement it at that level. =A0The behavior of the Z= E ini > parser won't change. the include logic will be at the fpm config loader/parser level but I DON'T want and I WON'T to change the ZE ini parser (even slightly). So I won't touch anything but the FPM files. I didn't want to create confusion or something on this point. It was not my point. To be precise, I wanted to call recursively the zend_parse_ini_file function but it's not possible (because of a global state -- state_stack -- variable in the ZE ini parser). So I'll continue to use the zend_parse_ini_file as is and change my code to make it works with this constrain. We can still start another discussion about adding include support or recursive support to ZE ini parser, but there is nothing to do with FPM and I won't do it anyway. hope it's clearer now ! ++ Jerome