On Tue, Mar 23, 2010 at 4:09 PM, Michael Shadle <mike...@gmail.com> wrote:
> On Tue, Mar 23, 2010 at 12:43 PM, Antony Dovgal <t...@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
