Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:47622 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 81509 invoked from network); 25 Mar 2010 21:54:06 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Mar 2010 21:54:06 -0000 Authentication-Results: pb1.pair.com smtp.mail=dreamcat4@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=dreamcat4@gmail.com; sender-id=pass; domainkeys=bad Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.225 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: dreamcat4@gmail.com X-Host-Fingerprint: 209.85.220.225 mail-fx0-f225.google.com Received: from [209.85.220.225] ([209.85.220.225:55103] helo=mail-fx0-f225.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 10/DD-11385-D7BDBAB4 for ; Thu, 25 Mar 2010 16:54:05 -0500 Received: by fxm25 with SMTP id 25so14350fxm.23 for ; Thu, 25 Mar 2010 14:54:01 -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 :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=TuEagoGlhdfkPz4KJfp35xXjMJJeUfJfdUEeGZQkIB8=; b=tJ/A6w+Ng6jBcAPxjmZbS4wHhnowFO+FVv1RZmoKrWpu3t7z9hz5B2GXMU3Qeorb9z kzRWgNAPf0Y073o9s3SJQQurqpOh3T3piyaSk86faCzrypzDQ+rR9Vo/ag8hM9AbYf4q bGQMuwlT1P10jzCz+Np10L96LDIFV9IDTz9/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=JSTmw7YjUCrgJ/IdFL6rL73PHd7UXr64T3kEQG5PUDu8gXW8UGohWqF4AZJNSv9txz gEnb3oG/n44HWyXl7fo+Q13hy1jvn0Swx0neIseVH5izUBz8cRngp7pPcII0gH5U+AXA isf6ZZobBHSOqI0BsrPBwO3UKb95KtcS+iaFE= MIME-Version: 1.0 Received: by 10.223.15.148 with SMTP id k20mr1317128faa.67.1269554041211; Thu, 25 Mar 2010 14:54:01 -0700 (PDT) In-Reply-To: <3bea96c41003250709jd391239te35ab88b46e4803e@mail.gmail.com> References: <4BA8EF6F.8010503@daylessday.org> <4BA92B72.1050207@daylessday.org> <7.0.1.0.2.20100323230046.12e71d80@zend.com> <7.0.1.0.2.20100324000837.13ff3080@zend.com> <4BA9CB98.6080102@daylessday.org> <7.0.1.0.2.20100324102437.0b491a68@zend.com> <4BA9D167.30006@daylessday.org> <99cf22521003240334y6fb76fbcs4347429f3be48d49@mail.gmail.com> <3bea96c41003250709jd391239te35ab88b46e4803e@mail.gmail.com> Date: Thu, 25 Mar 2010 21:53:41 +0000 Message-ID: <99cf22521003251453k4a9a5d4n5b7522f0c677d037@mail.gmail.com> To: =?UTF-8?B?SsOpcsO0bWUgTG95ZXQ=?= Cc: Antony Dovgal , Zeev Suraski , Derick Rethans , php-dev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] FPM RFC From: dreamcat4@gmail.com (dreamcat four) 2010/3/25 J=C3=A9r=C3=B4me Loyet : > I made some conf file exemple to really see what it will be: > > > > http://www.fatbsd.com/fpm/ini_with_sections_and_default_and_include.html > > From my point of vue, a conf file should be the less redundant as > possible and should be splitable in different files (in the case of > huge conf file, or when several administrators work on the conf files, > each pool has a file, and each pool administrator manage its own > file). So the INI syntax with sections to seraparate pools, with > include and the default pool is, for me, the best options we have > here. It's quite simple, it's clear and customizable. > > To compare, I put the same in the current XML syntax : > http://www.fatbsd.com/fpm/xml.html > > what do you think ? > > ++ Jerome http://www.fatbsd.com/fpm/ini_with_sections_and_default_and_include.html Hey, Thats the ticket Jerome! Maybe we have our winning INI scheme yet eh? Maybe id suggest (on top of that scheme), the main config file (which you labelled "/etc/fpm.conf"), to need only just the overidden options users want? So therefore the factory defaults file would be included earlier on, and tucked away somewhere else? Apart from that 1 suggestion, I cant see anything to improve upon. The standard seems good. I dont know if the whole internals list and / or Antony would agree but in anycase, this thread seems pretty exhausted now. If you intend to implement this Jerome, then perhaps (any time when / after you implement), just make new (seperate) RFC for that (just the ini). Which (obviously) can be attached as single dependancy of this RFC. That way, those comments / feedback can come directed back for just you (on your chosen, preferred ini implementation). And we don't get confused over the other ini examples. Best regards dreamcat4 dreamcat4@gmail.com