Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47507
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.177 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
         :content-type;
        b=a4xqBcjtRNGIETUkBM8Mj/6nFyAWzzsw/Wvw9C/XTC6WCv0mDovxhbEDs6ZGyGLvo4
         vJEDoJENFlJ32dPgxKG3RG+HnaT9nPF9HlyrUWCGfZdagJxuzNOKKGDlnasiWqolptiM
         GEjA+v5BCgO0LibjBsdyIiM+SKOfsRs//qgnY=
MIME-Version: 1.0
In-Reply-To: <bd9320b31003231309l1eb87626wa80438ccd9166eb1@mail.gmail.com>
References: <4BA8EF6F.8010503@daylessday.org> <4BA8F72E.5090701@sci.fi>
	 <4BA8F985.1090109@daylessday.org>
	 <bd9320b31003231226v302da734g391a9eff9494bccf@mail.gmail.com>
	 <4BA919D2.3060605@daylessday.org>
	 <bd9320b31003231309l1eb87626wa80438ccd9166eb1@mail.gmail.com>
Date: Tue, 23 Mar 2010 16:29:00 -0400
Message-ID: <ce6b011c1003231329k4a2c77f3ha08dbf90ae58f502@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=0016e6d26c5afa570604827da924
Subject: Re: [PHP-DEV] FPM RFC
From: ericleestewart@gmail.com (Eric Stewart)

--0016e6d26c5afa570604827da924
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Mar 23, 2010 at 4:09 PM, Michael Shadle <mike503@gmail.com> wrote:

> 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?"
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> From a testing standpoint, if this becomes a new sapi, do we need to
introduce a new construct for dealing with tests that need to run on this
sapi only?

Example: --FPM-- which would be similar to the --CGI-- construct which
denotes that test as cgi sapi only.

Eric Lee Stewart

--0016e6d26c5afa570604827da924--