Hi,

Antony Dovgal, one of core PHP developers has just made an
announcement that FPM (without PHP) has become an official PHP
project. Here is the full text of that announcement

---------------------------------------------------------
Hello all.

I'm glad to announce that we now have FPM SAPI available for testing
in a separate SVN branch.

You can check out its sources using the following command:
svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM
php_5_3_fpm

Building FPM is as easy as `./configure --enable-fpm && make install`.
After that you need to adjust the default config file (installed into
$prefix/etc)
and run `php-fpm`.


For those who don't know what FPM is: FPM (FastCGI Process Manager) is
an alternative
PHP FastCGI implementation with some additional features useful for
heavy-loaded sites.
These features include:
- advanced process management with graceful stop/start;
- ability to start workers with different uid/gid/chroot/environment
and different php.ini (replaces safe_mode);
- stdout & stderr logging;
- emergency restart in case of accidental opcode cache destruction;
- accelerated upload support;
- "slowlog";
- fastcgi_finish_request() - special function to finish request &
flush all data while
continuing to do something time-consuming (video converting, stats
processing etc.);
and some more.

You are welcome to test the code and report any issues to me (since
it's not fully official,
we don't have a category @ bugs.php.net yet).

--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP

Awesome!!!!!

Bout time!

-Jason

On Dec 4, 2009, at 8:16 AM, pcdinh <pcdinh@gmail.com> wrote:

> Hi,
>
> Antony Dovgal, one of core PHP developers has just made an
> announcement that FPM (without PHP) has become an official PHP
> project. Here is the full text of that announcement
>
> ---------------------------------------------------------
> Hello all.
>
> I'm glad to announce that we now have FPM SAPI available for testing
> in a separate SVN branch.
>
> You can check out its sources using the following command:
> svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM
> php_5_3_fpm
>
> Building FPM is as easy as `./configure --enable-fpm && make install`.
> After that you need to adjust the default config file (installed into
> $prefix/etc)
> and run `php-fpm`.
>
>
> For those who don't know what FPM is: FPM (FastCGI Process Manager) is
> an alternative
> PHP FastCGI implementation with some additional features useful for
> heavy-loaded sites.
> These features include:
> - advanced process management with graceful stop/start;
> - ability to start workers with different uid/gid/chroot/environment
> and different php.ini (replaces safe_mode);
> - stdout & stderr logging;
> - emergency restart in case of accidental opcode cache destruction;
> - accelerated upload support;
> - "slowlog";
> - fastcgi_finish_request() - special function to finish request &
> flush all data while
> continuing to do something time-consuming (video converting, stats
> processing etc.);
> and some more.
>
> You are welcome to test the code and report any issues to me (since
> it's not fully official,
> we don't have a category @ bugs.php.net yet).
>
> --
> Wbr,
> Antony Dovgal
> ---
> http://pinba.org - realtime statistics for PHP

Excellent news.

2009/12/4 Jason Giedymin <jason.giedymin@gmail.com>

> Awesome!!!!!
>
> Bout time!
>
> -Jason
>
>
> On Dec 4, 2009, at 8:16 AM, pcdinh <pcdinh@gmail.com> wrote:
>
> Hi,
>>
>> Antony Dovgal, one of core PHP developers has just made an
>> announcement that FPM (without PHP) has become an official PHP
>> project. Here is the full text of that announcement
>>
>> ---------------------------------------------------------
>> Hello all.
>>
>> I'm glad to announce that we now have FPM SAPI available for testing
>> in a separate SVN branch.
>>
>> You can check out its sources using the following command:
>> svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM
>> php_5_3_fpm
>>
>> Building FPM is as easy as `./configure --enable-fpm && make install`.
>> After that you need to adjust the default config file (installed into
>> $prefix/etc)
>> and run `php-fpm`.
>>
>>
>> For those who don't know what FPM is: FPM (FastCGI Process Manager) is
>> an alternative
>> PHP FastCGI implementation with some additional features useful for
>> heavy-loaded sites.
>> These features include:
>> - advanced process management with graceful stop/start;
>> - ability to start workers with different uid/gid/chroot/environment
>> and different php.ini (replaces safe_mode);
>> - stdout & stderr logging;
>> - emergency restart in case of accidental opcode cache destruction;
>> - accelerated upload support;
>> - "slowlog";
>> - fastcgi_finish_request() - special function to finish request &
>> flush all data while
>> continuing to do something time-consuming (video converting, stats
>> processing etc.);
>> and some more.
>>
>> You are welcome to test the code and report any issues to me (since
>> it's not fully official,
>> we don't have a category @ bugs.php.net yet).
>>
>> --
>> Wbr,
>> Antony Dovgal
>> ---
>> http://pinba.org - realtime statistics for PHP
>>
>

pcdinh wrote:
> Hi,
>
> Antony Dovgal, one of core PHP developers has just made an
> announcement that FPM (without PHP) has become an official PHP
> project. Here is the full text of that announcement

Excellent news!

On Fri, Dec 4, 2009 at 5:16 AM, pcdinh <pcdinh@gmail.com> wrote:
> Hi,
>
> Antony Dovgal, one of core PHP developers has just made an
> announcement that FPM (without PHP) has become an official PHP
> project. Here is the full text of that announcement

This was totally out of left field, I was talking to another PHP core
dev about whether or not it should be a new SAPI or bolted on to the
CGI/FCGI one, and then which pieces would be best (I still think the
management daemon shouldn't be thrown under the SAPI code)

No idea that Antony was working on this. It's a win though either way
as this should help get everything up to date, the cgi_main.c version
I believe is from 5.2.8 if that; that's probably the reason for the
5.3.x bugs people have been reporting.

Now I have to get on top of it from this new angle and figure out what
I can do (if anything) to keep things going now that it is looking to
be part of PHP core... I don't want the wish list and other feature
requests or things like that to be ignored!

2009/12/5 Michael Shadle <mike503@gmail.com>
>
> On Fri, Dec 4, 2009 at 5:16 AM, pcdinh <pcdinh@gmail.com> wrote:
> > Hi,
> >
> > Antony Dovgal, one of core PHP developers has just made an
> > announcement that FPM (without PHP) has become an official PHP
> > project. Here is the full text of that announcement
>
> This was totally out of left field, I was talking to another PHP core
> dev about whether or not it should be a new SAPI or bolted on to the
> CGI/FCGI one, and then which pieces would be best (I still think the
> management daemon shouldn't be thrown under the SAPI code)

Even if I think the same way as you, I think this is not so bad. We
have now an official integration into PHP and we can go forward safely
which is the most important thing for me.

There is many things to do:
1- check this version and confirm it works as expected (and correct it
if needed)
2- See with the php dev cores how to handle the managment of the project
3- continue developing what we're all waiting for

>
> No idea that Antony was working on this. It's a win though either way
> as this should help get everything up to date, the cgi_main.c version
> I believe is from 5.2.8 if that; that's probably the reason for the
> 5.3.x bugs people have been reporting.
>
> Now I have to get on top of it from this new angle and figure out what
> I can do (if anything) to keep things going now that it is looking to
> be part of PHP core... I don't want the wish list and other feature
> requests or things like that to be ignored!

2009/12/5 Jérôme Loyet <ml@fatbsd.com>:

> Even if I think the same way as you, I think this is not so bad. We
> have now an official integration into PHP and we can go forward safely
> which is the most important thing for me.
>
> There is many things to do:
> 1- check this version and confirm it works as expected (and correct it
> if needed)
> 2- See with the php dev cores how to handle the managment of the project
> 3- continue developing what we're all waiting for

no, like I said it's definitely a win. we just need to make sure we
can still get patches and influence and things in there.

php is a large project, it may take time for even the simplest of
patches to be merged, and that is what i am afraid of. nothing bad
about the php project, it just has a LOT of code and a huge audience
of users and developers/hackers all wanting attention from a small %
of people comparatively who can actually make those changes or commit
those patches.

On 5 дек, 12:35, Michael Shadle <mike...@gmail.com> wrote:
> php is a large project, it may take time for even the simplest of
> patches to be merged, and that is what i am afraid of. nothing bad
> about the php project, it just has a LOT of code and a huge audience
> of users and developers/hackers all wanting attention from a small %
> of people comparatively who can actually make those changes or commit
> those patches.

sorry but who the hell you are to decide what the php dev group and
what they should not? why are you going to care about php release
cycles when you committed 0 lines of code? they bring no difference in
sending floods and facebook from your iphone.

dreamcat4 said he has finished his work and prefered to give code
ownership to the -ru group; thanks to him for the job done, but the
project in fact remained without an owner so tony decided to push the
code into the official repo. and now when it is a sapi, php svn is the
where fpm should be, it won't be lost at least.

so long

On Tue, Dec 8, 2009 at 4:39 PM, fixxxer <fixxxerrr@gmail.com> wrote:

> sorry but who the hell you are to decide what the php dev group and
> what they should not? why are you going to care about php release
> cycles when you committed 0 lines of code? they bring no difference in
> sending floods and facebook from your iphone.

Who am I? I am the one that Andrei passed along the torch to,
regardless of contributing code. I was someone active in the community
who had expressed enough interested in keeping it alive that he
trusted me to inherit the domains and website and keep this thing
afloat as best as possible. It was obvious nobody else was around to
inherit it as everyone so far seems to have a lot of opinions yet
hasn't contributed code or donations or much at all. Kudos to the few
who edited docs on the wiki, or contributed, but a large % of people
just continued to use it despite the fact I was asking for any help
(money, coding, whatever) on the mailing lists.

I never said that I did not want it in PHP core, I was trying to work
with a PHP core developer already about getting it in and what the
best method would be to get it in. I wanted the stuff that belongs in
PHP core to be there for sure, but what might not be a good idea to be
in PHP core possibly separate.

> dreamcat4 said he has finished his work and prefered to give code
> ownership to the -ru group; thanks to him for the job done, but the
> project in fact remained without an owner so tony  decided to push the
> code into the official repo. and now when it is a sapi, php svn is the
> where fpm should be, it won't be lost at least.

dreamcat gave ownership to the -ru group? News to me. Fine with me.
I'm just a useless guy anyway right?

> so long

With this kind of attitude I wonder why I bother with any of this. I
may not have written any code but you have no clue what I was doing
behind the scenes to try to get people to start writing code for the
project including offering money out of MY OWN POCKET.

How about a hearty "thank you for doing the best you can do"

Funny, where were you when I was asking the list for coding help? Or
donations? Nowhere.

But look at you coming out of the woodwork to make sure to disrespect
me publicly for doing what exactly, trying to work out a method to get
what everyone wanted in the long run?

How about you go back on the PHP and PECL dev lists months ago and
look to see me petitioning for support or a sponsor to get it in to
PHP core or at least PECL. Or how I cornered Rasmus at a conference to
ask him about PHP-FPM and it's adoption into one of the above?

Tony has the knowledge to get it done and went ahead and did it. Kudos
x1000 for him. He's one of the idea folks to actually be involved in
this. However, he was not available or not interested at one point
because we've put this in front of him before, Andrei had a meeting
before handing off the project to me with a handful of people, I think
he was one of them, and Andrei decided to change the license and keep
it where it was at for now and not just "give up" and wait for someone
to bring it into PHP core.

Anyway, the code is now in core, people can submit patches to Tony. As
for the website and everything else, I'm still trying to determine
what use any of this may have anymore as the right place for
everything in PHP core is on php.net.

So maybe you can start hassling them about outdated documentation or
"why isn't this documented on the website" or how to get the latest
versions and such. Because it may be in an SVN branch in PHP core but
it is still a long way from being something supported and living on
php.net yet.

On 9 дек, 03:55, Michael Shadle <mike...@gmail.com> wrote:
> [..]

conference talks, petitions? ok, but no result. now it's commited onto
a branch. people writing code? it's the php dev team now. outdated? in
php.internals you've just admitted you did not even test 0.6 yourself.

ok, well, sorry for being rude, maybe i really have no information on
what happened behinds the scenes, but anyway you really should not
prevent anybody from taking fpm fully onto the php repo and
intergating it into the php development process, it is really the long
awaited event and the best possible option for fpm now.

On Tue, Dec 8, 2009 at 5:23 PM, fixxxer <fixxxerrr@gmail.com> wrote:
> On 9 дек, 03:55, Michael Shadle <mike...@gmail.com> wrote:
>> [..]
>
> conference talks, petitions? ok, but no result. now it's commited onto
> a branch. people writing code? it's the php dev team now. outdated? in
> php.internals you've just admitted you did not even test 0.6 yourself.

Correct, because it is not PRODUCTION READY. and i have my build
scripts for production hosting. also with the changes dreamcat was
doing and such i wasn't even sure myself where the best place to grab
the code was at for a while.

Either way it was handed to me by Andrei as "not production ready" and
was supposed to be a beta. As far as outdated documentation goes, I
was working with dreamcat to try to integrate his new docs directly
into the php-fpm.org website, but mediawiki's markdown plugins I was
using were not working correctly, and he was using markdown syntax. He
also did that all on his own, I was trying to steer things in to one
source the entire time, that was the point of getting the domains from
Andrei to begin with.

Also, I cannot control the outcome of talking to people at conferences
or petitioning for help. If I could, there would be no hungry people
in the world, whales and dolphins would be safe, there would be world
peace, and I'd be married to a supermodel.

> ok, well, sorry for being rude, maybe i really have no information on
> what happened behinds the scenes, but anyway you really should not
> prevent anybody from taking fpm fully onto the php repo and
> intergating it into the php development process, it is really the long
> awaited event and the best possible option for fpm now.

I am not preventing anyone. I *asked* for it. I was just trying to
work out some specifics and ask if it can be split into two parts.

On Wed, Dec 9, 2009 at 4:30 AM, Michael Shadle <mike503@gmail.com> wrote:
> On Tue, Dec 8, 2009 at 5:23 PM, fixxxer <fixxxerrr@gmail.com> wrote:
>> On 9 дек, 03:55, Michael Shadle <mike...@gmail.com> wrote:
>>> [..]
>>
>> conference talks, petitions? ok, but no result. now it's commited onto
>> a branch. people writing code? it's the php dev team now. outdated? in
>> php.internals you've just admitted you did not even test 0.6 yourself.
>
> Correct, because it is not PRODUCTION READY. and i have my build
> scripts for production hosting. also with the changes dreamcat was
> doing and such i wasn't even sure myself where the best place to grab
> the code was at for a while.

Guys, please, calm down. Don't look at this project in the terms of
ownership or independence or I-did-that-and-that or who-are-you and so
on. Finally it's BSD! We all want this project to be alive and we need
more unity and respect. I believe that the best future of the project
is to be in PHP repo. But this process is in the very beginning. I
think there is a lot of work to be done. There is nothing to discuss
yet - it's in separate development branch, that's all. How everyone
can help - just try to download it and to run and report everything.
That's all for now.

About two parts. I think that everything should go into PHP just
because good software must have simple and clear installation and
support. FPM support is great but FPM installation is still tricky ;)
Let it be as simple as 1) get PHP 2) ./configure --with-fpm. And if
everything goes into PHP all the pain in the ass with package
distribution - it will disappear someday almost automatically. The
only way to fix it all at once - to push everything into PHP.

--

wbr,
fisher

On Tue, Dec 8, 2009 at 11:59 PM, Alexey A. Rybak <alexey.rybak@gmail.com> wrote:
> On Wed, Dec 9, 2009 at 4:30 AM, Michael Shadle <mike503@gmail.com> wrote:
>> On Tue, Dec 8, 2009 at 5:23 PM, fixxxer <fixxxerrr@gmail.com> wrote:
>>> On 9 дек, 03:55, Michael Shadle <mike...@gmail.com> wrote:
>>>> [..]
>>>
>>> conference talks, petitions? ok, but no result. now it's commited onto
>>> a branch. people writing code? it's the php dev team now. outdated? in
>>> php.internals you've just admitted you did not even test 0.6 yourself.
>>
>> Correct,  because it is not PRODUCTION READY. and i have my build
>> scripts for production hosting. also with the changes dreamcat was
>> doing and such i wasn't even sure myself where the best place to grab
>> the code was at for a while.
>
> Guys, please, calm down. Don't look at this project in the terms of
> ownership or independence or I-did-that-and-that or who-are-you and so
> on. Finally it's BSD! We all want this project to be alive and we need
> more unity and respect. I believe that the best future of the project
> is to be in PHP repo. But this process is in the very beginning. I
> think there is a lot of work to be done. There is nothing to discuss
> yet - it's in separate development branch, that's all. How everyone
> can help - just try to download it and to run and report everything.
> That's all for now.
>
> About two parts. I think that everything should go into PHP just
> because good software must have simple and clear installation and
> support. FPM support is great but FPM installation is still tricky ;)
> Let it be as simple as 1) get PHP 2) ./configure --with-fpm. And if
> everything goes into PHP all the pain in the ass with package
> distribution - it will disappear someday almost automatically. The
> only way to fix it all at once - to push everything into PHP.

While I disagree with this, it could be as easy as a second package
for the manager daemon piece, the feedback has been 99.9% "no keep it
together" - I'm not really fighting the flow anymore, it's already
together, now it's having to be redefined in PHP core terms (see our
php dev discussion on how the configuration format might change to ini
style...) because the daemon now needs to align with how people are
used to using PHP. It seems out of place for a daemon and different
configuration format to be inside of PHP core, so either it moves out
(which nobody wants apparently, and I don't see it as a big deal if
done right, I see it as much more flexibility, even perhaps a PECL
module to keep it close to PHP still) or it should be redefined to map
to the rest of PHP. There's been a couple pretty gross looking
configuration ideas so far in the mix - really stretching what an ini
file should have in it IMHO.

Anyway, I do apologize for defending myself. All I've ever wanted to
do is advance this project further. Getting it into PHP core was one
of the goals (although I saw it a little different) and was trying to
get some other things done too hopefully before that happened, so
those things were done before being put in to the big codebase which
we have limited control over.

On Tue, Dec 8, 2009 at 11:59 PM, Alexey A. Rybak <alexey.rybak@gmail.com> wrote:

> Guys, please, calm down. Don't look at this project in the terms of
> ownership or independence or I-did-that-and-that or who-are-you and so
> on. Finally it's BSD! We all want this project to be alive and we need
> more unity and respect. I believe that the best future of the project
> is to be in PHP repo. But this process is in the very beginning. I
> think there is a lot of work to be done. There is nothing to discuss
> yet - it's in separate development branch, that's all. How everyone
> can help - just try to download it and to run and report everything.
> That's all for now.

Anyway, enough about the past, let's focus on the future. :)

I am now trying to figure out what php-fpm.org should be focused on.
If this does become part of PHP core, then the documentation best
resides on php.net; examples will be there too. The code will be there
as well as will bugs.

So php-fpm.org won't really be relevant anymore at some point.

Any wishlist items could be logged as feature requests in PHP's bug
tracker, and anyone who is willing to code them can do so and submit
patches just like any other portion of PHP.

Anyone have any ideas on where to go from here? Obviously legacy
PHP-FPM will be in use for a while still; I think it makes sense to
keep all the old documentation and such up until it becomes part of an
official PHP release (right now I think they're trying to wait until
5.3.3, Someone brought up why it can't just be shipped with 5.3.2 and
marked "experimental", I think other PHP core devs are fans of that
too, so it's a bit of a political battle, things like this I had
wished to avoid :) I am trying to push for that myself)

The quicker it gets in to an actual published build of PHP the better
now. Right now I can't even check out the source tree because my svn
checkout fails on some documents with a "!" character in them. :( I
believe Tony has it being built without an issue but I wanted to play
around with it myself, and could put up on the site the instructions
to grab it, but I can't sell something I can't use myself!

I'm open to ideas.

> The quicker it gets in to an actual published build of PHP the better
> now. Right now I can't even check out the source tree because my svn
> checkout fails on some documents with a "!" character in them. :( I
> believe Tony has it being built without an issue but I wanted to play
> around with it myself, and could put up on the site the instructions
> to grab it, but I can't sell something I can't use myself!
>
It compiles weel sinces the annoucement and it works (with chroot). I
just checked the phpinfo page to work properly.

All I did is:
svn checkout URL
cd PHP_5_3_FPM
../builconf
../configure --enable-fpm
make
../sapi/fpm/php-fpm -y /etc/php-fpm.conf

What did you exactly do ? and what are the error messages ?

++ Jerome

I got svn to check it out today. Someone must have checked in some
bogus files for a bit when I was attempting to check it out.

Takes -forever- to check out, doesn't it? :) They're really pushing
the limits of svn I think! heh.

I think now I can update the downloads page possibly with the three
download options. the SVN repo from php.net, the launchpad URLs for
0.6.x series, and the legacy patch (which still works excellent for
5.2.x)



2009/12/9 Jérôme Loyet <ml@fatbsd.com>:
>> The quicker it gets in to an actual published build of PHP the better
>> now. Right now I can't even check out the source tree because my svn
>> checkout fails on some documents with a "!" character in them. :( I
>> believe Tony has it being built without an issue but I wanted to play
>> around with it myself, and could put up on the site the instructions
>> to grab it, but I can't sell something I can't use myself!
>>
> It compiles weel sinces the annoucement and it works (with chroot). I
> just checked the phpinfo page to work properly.
>
> All I did is:
> svn checkout URL
> cd PHP_5_3_FPM
> ./builconf
> ./configure --enable-fpm
> make
> ./sapi/fpm/php-fpm -y /etc/php-fpm.conf
>
> What did you exactly do ? and what are the error messages ?
>
> ++ Jerome
>

On 9 дек, 15:18, Michael Shadle <mike...@gmail.com> wrote:
> > Guys, please, calm down. Don't look at this project in the terms of
> > ownership or independence or I-did-that-and-that or who-are-you and so
> > on. Finally it's BSD! We all want this project to be alive and we need
> > more unity and respect. I believe that the best future of the project
> > is to be in PHP repo. But this process is in the very beginning. I
> > think there is a lot of work to be done. There is nothing to discuss
> > yet - it's in separate development branch, that's all. How everyone
> > can help - just try to download it and to run and report everything.
> > That's all for now.
>
> > About two parts. I think that everything should go into PHP just
> > because good software must have simple and clear installation and
> > support. FPM support is great but FPM installation is still tricky ;)
> > Let it be as simple as 1) get PHP 2) ./configure --with-fpm. And if
> > everything goes into PHP all the pain in the ass with package
> > distribution - it will disappear someday almost automatically. The
> > only way to fix it all at once - to push everything into PHP.
>
> While I disagree with this, it could be as easy as a second package
> for the manager daemon piece, the feedback has been 99.9% "no keep it
> together" - I'm not really fighting the flow anymore, it's already
> together, now it's having to be redefined in PHP core terms (see our
> php dev discussion on how the configuration format might change to ini
> style...) because the daemon now needs to align with how people are
> used to using PHP. It seems out of place for a daemon and different
> configuration format to be inside of PHP core, so either it moves out
> (which nobody wants apparently, and I don't see it as a big deal if
> done right, I see it as much more flexibility, even perhaps a PECL
> module to keep it close to PHP still) or it should be redefined to map
> to the rest of PHP. There's been a couple pretty gross looking
> configuration ideas so far in the mix - really stretching what an ini
> file should have in it IMHO.
>
> Anyway, I do apologize for defending myself. All I've ever wanted to
> do is advance this project further. Getting it into PHP core was one
> of the goals (although I saw it a little different) and was trying to
> get some other things done too hopefully before that happened, so
> those things were done before being put in to the big codebase which
> we have limited control over.

OK, i'm apologizing for my tone and reaction; i believe you're a nice
guy and try to do all the best you can. But your posts in .internals
just bring confusion to the dev team members; the initial purpose of
adding the fpm branch was to bring some attention and find someone to
maintain the code, and here you appear - what a reader would think -
that it's ok with code maintanence and support and there is nothing
they can help with, while the situation is absolutely opposite.

Separate daemon.. how do you imagine it? A specific fpm sapi which is
useless without this external daemon? Has absolutely no sense.
Introducing additional master-worker intercommunication protocol, kind
of python SCGI? Overcomplicated, brings nothing but additional layer
to support, and can introduce performance issues. May be the current
solution is not very beautiful from an architectural point of view
but it's best for performance.

On Wed, Dec 9, 2009 at 7:53 AM, fixxxer <fixxxerrr@gmail.com> wrote:

> OK, i'm apologizing for my tone and reaction; i believe you're a nice
> guy and try to do all the best you can. But your posts in .internals
> just bring confusion to the dev team members; the initial purpose of
> adding the fpm branch was to bring some attention and find someone to
> maintain the code, and here you appear - what a reader would think -
> that it's ok with code maintanence and support and there is nothing
> they can help with, while the situation is absolutely opposite.

I apologize if that's how it came out. I was asking for their help in
general, whether it be still standalone, partially merged, fully
merged, whatever.

If you look at php-dev right now you'll see already discussions on how
to modify FPM so it maps to core, and already not able to necessarily
hammer down a configuration syntax in INI format quite yet because it
can be done a few ways... but they definitely want it changed to match
normal PHP ini style.

> Separate daemon.. how do you imagine it? A specific fpm sapi which is
> useless without this external daemon? Has absolutely no sense.
> Introducing additional master-worker intercommunication protocol, kind
> of python SCGI? Overcomplicated, brings nothing but additional layer
> to support, and can introduce performance issues. May be the current
> solution  is not very beautiful from an architectural point of view
> but it's best for performance.

This is where it comes in - I was asking for advice from people
knowledgeable in the specifics if this would be a performance issue,
if it was smarter to add in APIs/hooks/command line arguments to the
FPM SAPI and then allow for a separate management daemon (which could
live in PECL, or anywhere) and/or allow for multiple daemons in the
future if people did not like how PHP-FPM controlled it or PHP-FPM did
not work the way they wanted to, they could use a different one or
make their own.

Basically bringing an open management API to the world... although it
wouldn't be a priority to expose it, but mainly just for PHP-FPM to
use it for now, but other people -could- use it in the future.

It could still be very easy to package and support, it wouldn't be
very difficult when it came down to it. But we have pushed management
daemon functionality now over to the PHP team - who will accept
patches and such, and maybe work on better functionality, but unless
they have an interest in it, it's just another vector of support they
have to work with, not just a SAPI but something that controls the
SAPI as well. Yes, the PHP internals pieces of it are definitely good
to live there as they will be updated and maintained, I just worry
that the management pieces of it like adaptive process spawning and
such still won't be any of their concern so we're back to having to
find developers for it anyway.

First off, Michael you're doing a great service and its noted, and I'm
not saying that just because we both share a great first name.

Now, regarding php-fpm as a separate package, the deamon point is a
valid reason to package it separately. But then again, PHP's own
fastcgi sapi can run in daemon mode as we all know and its bundled
in.

Next up is the xml config: why do we have that? Is it just a legacy
from the project's beginning or is there a real technical advantage
for it to exist?

> Next up is the xml config: why do we have that? Is it just a legacy
> from the project's beginning or is there a real technical advantage
> for it to exist?
>
it's a legacy and it was about to be changed before integration into
php tree. That's why all this discution about the conf file syntax.