On Mon, Dec 7, 2009 at 2:01 AM, Michael Shadle wrote:
On Mon, Dec 7, 2009 at 1:25 AM, Antony Dovgal 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
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.