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
