On Mon, Dec 7, 2009 at 2:01 AM, Michael Shadle <mike...@gmail.com> wrote: > On Mon, Dec 7, 2009 at 1:25 AM, Antony Dovgal <t...@daylessday.org> wrote: > >> That's the thing I want to avoid, actually. >> Moving something out of PHP just because you're afraid of its release cycles >> means you make it harder to maintain, not easier. > > Even if it is just the management component of it? > > Any of the PHP internals will still stay inside of PHP. It will only > be the daemon portion that tells the new SAPI how to behave (spawn > more under this pool, kill this child, do that?) etc?
Or, perhaps move it into PECL at least? There are still many things TBD in PHP-FPM, one of them was a discussion about possibly changing the model to make it more accommodating for shared hosting providers. Other features grokked from the wishlist/would be logged as "feature requests" when I had setup the bug tracker: - Adaptive process support (the major thing lacking) - CPU affinity/load balancing - Config file syntax change - Syslog support - Per-pool php.ini file (should be easy) - See if the normal libevent or libev could handle all the needs and not a patched copy anymore (or get with the libevent team) - Metrics/reporting, possibly like postfix's anvil reports out, or a way to query the SAPI to get an idea of usage At the moment unless these changes are ready for commitment into a PHP beta build they won't get out until the next one, and so on... at least with PECL there is a clear delineation from core. Anyway, as acting manager for the project I really would like to be able to figure out the future - what we should be doing on the side (obviously trying to work on code and submit it when ready) but do we still maintain the documentation, or will it migrate to php.net then? Since the SAPI includes the config file, now all of a sudden that becomes thrown under the PHP core umbrella for documentation, and the existing XML configuration (and desired nginx style configuration) both do not line up with the INI style configuration that PHP users are used to. This might be one of the main reasons why I think having the daemon/management portion be split out. Otherwise, if it is part of core, then core has to have pages with documentation for all of this as well, bug tracking for it, etc. Quite possibly, if split apart, a better management daemon or tool would be developed as well, as the API would be in place to manage the FPM SAPI'ed PHP processes from an external manager. (Heck, do I see control panel integration points? cpanel/plesk/etc. could now define PHP process quotas per user for example?) Just spitballing here. You're ultimately the master of this domain. I also don't want to spam the list. I'm more than happy to pro/con this offline with you. Or have you tell me flat out what I should be changing on the community side of things. "Keep your own svn, but keep it in sync with our branch. Once a feature is complete and assumed bug free, then send the patch to us" or "Use php.net for the bugtracker now, there is no need for an external website anymore either. Documentation will also be hosted on php.net as well" ... etc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
