2009/12/7 Michael Shadle <mike...@gmail.com>: > 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? >
Before integration of php-fpm in the official php tree I agreed with you about separating daemon stuff out of php tree and include only necessary functions (communication about spawning, chroot, ...) in php-fastcgi (cgi sapi). But as it's been totaly included as an independant sapi, I don't see any benefit to split. The fpm sapi would be only a patch version of the cgi sapi in order to work exclusively with an external software. This is illogical to me. And as tony has worked on this integration it would be a waste of time to change this. I hear you concerns about frequency of releases. Why don't follow patch against official release on the php-fpm website or something like that ? We have some thinking to do to find a solution that pleases everyone. > Or, perhaps move it into PECL at least? What PECL can help here ? Is PECL just a compiled packages library for PHP ? > > 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 > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
