Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47506
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
DomainKey-Status: bad
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=pL1Px6yAt3GTBp5MvIveIlxNLEgQafEovMgeiT9pdNV+1e3MwH717SPK/hCqJ43ZUr
         1OXdbHqCww1RjId+PHG5RtK6V8PQBZMhDyR45DFSHWEWK7pCGMFJC1acVGowCbGYu/0Q
         aJqHYu+yqEqfA9Js+dyyH4k0UtYoFL+T3VGV4=
MIME-Version: 1.0
In-Reply-To: <4BA919D2.3060605@daylessday.org>
References: <4BA8EF6F.8010503@daylessday.org> <4BA8F72E.5090701@sci.fi>
	 <4BA8F985.1090109@daylessday.org>
	 <bd9320b31003231226v302da734g391a9eff9494bccf@mail.gmail.com>
	 <4BA919D2.3060605@daylessday.org>
Date: Tue, 23 Mar 2010 13:09:41 -0700
Message-ID: <bd9320b31003231309l1eb87626wa80438ccd9166eb1@mail.gmail.com>
To: Antony Dovgal <tony@daylessday.org>
Cc: php-dev <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] FPM RFC
From: mike503@gmail.com (Michael Shadle)

On Tue, Mar 23, 2010 at 12:43 PM, Antony Dovgal <tony@daylessday.org> wrote:

> I mentioned it, albeit briefly:
> * basic SAPI status info (similar to Apache mod_status)

Missed it (oops)

> We've discussed this many times and I thought it's pretty clear that php.ini
> syntax won't fit in this situation - the requirements are completely different.
>
>> - this will make it easier to adopt
>
> I don't see how.

When people see XML a lot of people have tried to use xpath and other
XML functionality - when really it's not a full-on XML document at
all. (People have asked on the mailing list) - also it's an external
configuration file with it's own syntax. It feels a bit foreign from
how people are used to configuring PHP. (I admit I do not have a
better alternative other than trying the php.ini approach which I
guess has been shot down now) - I am looking for the easiest path for
people to use this, that's all.

Perhaps some php.ini options for the pid file, config file, etc. So it
is not defined at compile time?

Also one other feature that would be neat is an "include"
functionality in the config file, which could help automated pool
definitions from scripts be created. A bit OT for this though.

> They can do it any time - testing and reporting issues is a lot of work.

I have a lot of machines at my disposal and such and would love a way
to be able to put PHP-FPM through it's paces by running test scripts
or anything. I personally do not know how to create them nor what
portions are useful to test (tricky internals that might break under
certain situations, things that might have been changed when you moved
it from launchpad -> PHP SVN, etc.) - note that PHP-FPM for PHP 5.2.x
(the patch) seems to be solid as a rock, but 5.3 has had a handful of
issues or other complaints. So there is some fundamental differences
somewhere and those are the kind of things I'd like to figure out how
to get automated testing on...

> Patches are also appreciated, no need to wait for a 'go ahead' from anyone to do this.

I just thought of a slightly more formal approach - perhaps a small
roadmap or prioritization of features - something small would be easy
to adopt in 5.4 without causing possible instability - but something
larger might be "don't bother with that right now - it is too big of a
change and won't make it in to 5.4 anyway. how about you tackle this
first?"