Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:47984 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16780 invoked from network); 15 Apr 2010 15:08:28 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Apr 2010 15:08:28 -0000 Authentication-Results: pb1.pair.com smtp.mail=tyra3l@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=tyra3l@gmail.com; sender-id=pass; domainkeys=bad 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:38008] helo=mail-bw0-f219.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 88/65-22079-CEB27CB4 for ; Thu, 15 Apr 2010 11:08:28 -0400 Received: by bwz19 with SMTP id 19so103489bwz.1 for ; Thu, 15 Apr 2010 08:08:25 -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=f3jUdMaWZEoVhPZ5OtDmgRM5KnZ3fXwU1PNUDrA0o8w=; b=T3XTCZIvJaVO5emosuW8YeNF26La+ehNLuEfp2wKNjlI69VS1/W1hjRE4flDh43TAC aGF+ROjqTDI0tVRdD7wNWvjKpZ6t2Ge5EKGE943QcuMy+a5icJwnDo/aCYTLrH8ftXm7 JHi+e/5qt21mcMi2YaO8Y1/g9uKa1HUIloAMA= 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=pnIQr9CsIix0FjnRZMj1+czzR5JD+lEFzPrTg4RrrAQPjF25ZRYgJkvRLZNB2SmWNZ dRB8qa9qP0+UGpQtItFJmiityscmvDr72HTPLXu5B3OaQT8HwOCTfC7MxzaRfJsvy+Ft JVQvBdGQW0fOiTKdKFDzeROmc2q285j8iMQec= MIME-Version: 1.0 Received: by 10.204.123.20 with HTTP; Thu, 15 Apr 2010 08:08:25 -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 17:08:25 +0200 Received: by 10.204.4.153 with SMTP id 25mr236456bkr.77.1271344105321; Thu, 15 Apr 2010 08:08:25 -0700 (PDT) Message-ID: To: Zeev Suraski Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary=00151758ffd8c8f59f048447ddde Subject: Re: [PHP-DEV] [RFC] FPM INI syntax From: tyra3l@gmail.com (Ferenc Kovacs) --00151758ffd8c8f59f048447ddde Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 15, 2010 at 4:13 PM, Zeev Suraski wrote: > 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. =C3=82 There weren't any plans to touch the .i= ni 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. It doesn't mean the pars= er > itself will support include. BTW - 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. The behavior of the ZE = ini > parser won't change. > > "There weren't any plans to touch the .ini parser itself in any way." I think that for the long run, it would be better, that the php-fpm and the php core only differs on the parts where it's neccessary (either it will be merged to the core or not), and I think it is not neccessary, for example the additional ini file parsing doesn't need this modification, why should the php-fpm? Tyrael --00151758ffd8c8f59f048447ddde--