On Tue, 23 Mar 2010, Antony Dovgal wrote:
> Derick (and other people) asked me to create an RFC for FPM describing
> what it is and why do we need it. Quite.. ahem.. laconic version of
> such RFC can be found here: http://wiki.php.net/rfc/fpm
>
> I'm open for your questions.
Can you merge it t
2010/3/25 Jérôme Loyet :
> Is there any sapi with directives in php.ini ? I can't see any reasons
> to have some FPM specifics into php.ini.
>
> To change the default conf file, juste specified it in the commande
> line like any other daemon you have running on your boxes.
php-fpm isn't launched
2010/3/25 dreamcat four :
> If you intend to implement this Jerome, then perhaps (any time when /
> after you implement), just make new (seperate) RFC for that (just the
> ini). Which (obviously) can be attached as single dependancy of this
> RFC. That way, those comments / feedback can come direc
2010/3/25 Michael Shadle :
> 2010/3/25 dreamcat four :
>
>> If you intend to implement this Jerome, then perhaps (any time when /
>> after you implement), just make new (seperate) RFC for that (just the
>> ini). Which (obviously) can be attached as single dependancy of this
>> RFC. That way, those
2010/3/25 Jérôme Loyet :
> I made some conf file exemple to really see what it will be:
>
>
>
> http://www.fatbsd.com/fpm/ini_with_sections_and_default_and_include.html
>
> From my point of vue, a conf file should be the less redundant as
> possible and should be splitable in different files (in t
On Thu, Mar 25, 2010 at 12:47 PM, Antony Dovgal wrote:
> You can as well stop declaring (!?) what FPM should and what it shoud not
> and start doing something useful instead.
> Writing some code might be a good start for you.
As someone Andrei somewhat entrusted to try to keep the dream of FPM
a
On 25.03.2010 21:30, Michael Shadle wrote:
> 2010/3/25 Jérôme Loyet :
>
>> ** Default Section **
>> Talking about redundancy. When there is more than one pool, there is
>> several parameters which remain the same. Why should we type them
>> several time ? The idea is to define a special pool, whic
2010/3/25 Jérôme Loyet :
> ** Default Section **
> Talking about redundancy. When there is more than one pool, there is
> several parameters which remain the same. Why should we type them
> several time ? The idea is to define a special pool, which will not be
> started but only be used as a "temp
2010/3/24 dreamcat four :
> Wait a sec,
>
> As a previous maintainer, I dont believe I should really have as much
> weight in this decision as the rest of the internals group. It does
> seem like plenty enough discussion over this INI business. Theres now
> over 40+ mails on this thread, mostly abo
Wait a sec,
As a previous maintainer, I dont believe I should really have as much
weight in this decision as the rest of the internals group. It does
seem like plenty enough discussion over this INI business. Theres now
over 40+ mails on this thread, mostly about ini. And this is not the
only disc
At 10:46 24/03/2010, Antony Dovgal wrote:
On 24.03.2010 11:29, Zeev Suraski wrote:
>>I think you're missing something.
>>
>>I don't care if FPM is in or out of the core.
>
> FWIW, I don't think it's a good start for a component that goes into
> our distribution.
> In this case I'm willing to tak
On 24.03.2010 11:29, Zeev Suraski wrote:
>>I think you're missing something.
>>
>>I don't care if FPM is in or out of the core.
>
> FWIW, I don't think it's a good start for a component that goes into
> our distribution.
> In this case I'm willing to take responsibility for doing the
> conversio
At 10:21 24/03/2010, Antony Dovgal wrote:
On 24.03.2010 01:16, Zeev Suraski wrote:
> For me it is a requirement before the code makes it into a released
> version of PHP, and I think many others think that way if past
> discussions are any indication. That's what RFCs are for - if people
> can
On 24.03.2010 01:16, Zeev Suraski wrote:
> For me it is a requirement before the code makes it into a released
> version of PHP, and I think many others think that way if past
> discussions are any indication. That's what RFCs are for - if people
> can just go ahead and implement their original
On 24.03.2010 09:36, Stanislav Malyshev wrote:
> fpm.myworker.server.start_servers = 20
> fpm.myworker.php_defines.memory_limit = 64M
>
> etc. It's not that bad.
"Not that bad" doesn't sound very convincing.
I'd personally prefer something better than that.
> As for spaces in pool names - come
On 24.03.2010, at 0:58, Antony Dovgal wrote:
> On 24.03.2010 00:05, Zeev Suraski wrote:
>>> How do you propose to describe the same set of options using php.ini syntax?
>>> Yes, simple things like "value=Yes/No" or "value=DIR" fit just fine
>>> into php.ini.
>>> But how would decribe a set of po
Hi!
I'm sure you understand that nesting makes things much more easier to read.
fpm.workers..pm.dynamic.start_servers is
not my preferred syntax.
This is actually highly debatable. Nesting does not allow you an easy
way to know where each value belongs to - you'd have to climb up the
tree a
Hi!
I want PHP core to do it. Not only for FPM but for many other reasons. :)
MySQL does a !includedir thing...
Oh, well, that's another thing. Do an RFC then :)
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Inte
2010/3/23 Stanislav Malyshev :
> Actually, if you have extension parsing the .ini, nobody prevents you from
> having:
>
> include[]=another.ini
>
> and have your extension interpret it as it wishes (i.e parse another file).
> Only problem you have is if you want PHP to do it automatically for you.
Hi!
That's not true. You configure the fastcgi SAPI for lighttpd in the
lighttpd config, in LUA. Sure, it's the web-server side of it, but it's
no different from sapi/fpm which is its own little wrapper instead of
the one that comes with lighttpd.
Actually, it is different. lighty is not a par
Hi!
That was something I brought up to internals a while back, was adding
in the ability for includes in the php.ini file. I can see many usage
models for this, from distributions to web hosting managers.
Actually, if you have extension parsing the .ini, nobody prevents you
from having:
inc
At 00:33 24/03/2010, Derick Rethans wrote:
On Wed, 24 Mar 2010, Zeev Suraski wrote:
> At 00:01 24/03/2010, Derick Rethans wrote:
> > I don't see how this actually matters. None of the other SAPIs are
> > configured with a php.ini syntax.
>
> None of the other SAPIs are configured, period.
That
On Tue, Mar 23, 2010 at 11:33 PM, Derick Rethans wrote:
> That's not true. You configure the fastcgi SAPI for lighttpd in the
> lighttpd config, in LUA. Sure, it's the web-server side of it, but it's
> no different from sapi/fpm which is its own little wrapper instead of
> the one that comes with
At 00:25 24/03/2010, Antony Dovgal wrote:
On 24.03.2010 01:08, Zeev Suraski wrote:
> At 23:58 23/03/2010, Antony Dovgal wrote:
>>Okay, here is XML based config quickly converted to php.ini-style syntax:
>
> Here's mine - a bit more representative of how .ini files look
> instead of trying to con
On Tue, Mar 23, 2010 at 10:16 PM, Zeev Suraski wrote:
> At 00:01 24/03/2010, Derick Rethans wrote:
>>
>> I don't see how this actually matters. None of the other SAPIs are
>> configured with a php.ini syntax.
>
> None of the other SAPIs are configured, period; The little configuration
> they do h
On Wed, 24 Mar 2010, Zeev Suraski wrote:
> At 00:01 24/03/2010, Derick Rethans wrote:
> > I don't see how this actually matters. None of the other SAPIs are
> > configured with a php.ini syntax.
>
> None of the other SAPIs are configured, period.
That's not true. You configure the fastcgi SAPI f
On 24.03.2010 01:08, Zeev Suraski wrote:
> At 23:58 23/03/2010, Antony Dovgal wrote:
>>Okay, here is XML based config quickly converted to php.ini-style syntax:
>
> Here's mine - a bit more representative of how .ini files look
> instead of trying to convert a nested XML file:
I'm sure you under
At 00:01 24/03/2010, Derick Rethans wrote:
I don't see how this actually matters. None of the other SAPIs are
configured with a php.ini syntax.
None of the other SAPIs are configured, period; The little
configuration they do have is done using php.ini.
This SAPI requires much more configurati
At 23:58 23/03/2010, Antony Dovgal wrote:
Okay, here is XML based config quickly converted to php.ini-style syntax:
Here's mine - a bit more representative of how .ini files look
instead of trying to convert a nested XML file:
[globals]
pid_file = /usr/local/var/run/php-fpm.pid
error_log = /
On Tue, Mar 23, 2010 at 8:55 PM, Antony Dovgal wrote:
> Now I was never an XML fan myself, but I think THIS particular XML config file
> is even easier to read and understand than php.ini.
Actually, I agree with Antony on this point. The existing XML config
file is pretty easy to read. I didn't i
On Tue, Mar 23, 2010 at 2:58 PM, Antony Dovgal wrote:
> Okay, here is XML based config quickly converted to php.ini-style syntax:
> ==
> [fpm.flobals]
> pid_file = /usr/local/var/run/php-fpm.pid
> error_log = /usr/local/var/l
On Tue, 23 Mar 2010, Zeev Suraski wrote:
> At 22:58 23/03/2010, Antony Dovgal wrote:
>
> > On 03/23/2010 11:54 PM, Zeev Suraski wrote:
> > > At 22:44 23/03/2010, Jérôme Loyet wrote:
> > >>In fact with INI syntax, there is a serious missing cause there is no
> > >>include system shiped with. And w
On 24.03.2010 00:05, Zeev Suraski wrote:
>>How do you propose to describe the same set of options using php.ini syntax?
>>Yes, simple things like "value=Yes/No" or "value=DIR" fit just fine
>>into php.ini.
>>But how would decribe a set of pools each with its own set of options?
>>(taking into acco
At 22:55 23/03/2010, Antony Dovgal wrote:
On 03/23/2010 11:31 PM, Zeev Suraski wrote:
> It's not clear at all. In fact I think it was very clear that using
> php.ini syntax (together with sections if necessary) is very much an
> option, and I think mostly everyone here leaned towards it.
Just
At 22:58 23/03/2010, Antony Dovgal wrote:
On 03/23/2010 11:54 PM, Zeev Suraski wrote:
> At 22:44 23/03/2010, Jérôme Loyet wrote:
>>In fact with INI syntax, there is a serious missing cause there is no
>>include system shiped with. And with FPM as there is potentialy many
>>"vhosts", it's necessa
On Tue, Mar 23, 2010 at 1:55 PM, Antony Dovgal wrote:
> Now I was never an XML fan myself, but I think THIS particular XML config file
> is even easier to read and understand than php.ini.
There was one other suggestion / something Andrei wanted to do (at
least he mentioned to me) and that was c
On 03/23/2010 11:54 PM, Zeev Suraski wrote:
> At 22:44 23/03/2010, Jérôme Loyet wrote:
>>In fact with INI syntax, there is a serious missing cause there is no
>>include system shiped with. And with FPM as there is potentialy many
>>"vhosts", it's necessary to have an include system to feet all syst
On 03/23/2010 11:31 PM, Zeev Suraski wrote:
> It's not clear at all. In fact I think it was very clear that using
> php.ini syntax (together with sections if necessary) is very much an
> option, and I think mostly everyone here leaned towards it.
Just take a look at it:
http://svn.php.net/viewv
At 22:44 23/03/2010, Jérôme Loyet wrote:
In fact with INI syntax, there is a serious missing cause there is no
include system shiped with. And with FPM as there is potentialy many
"vhosts", it's necessary to have an include system to feet all system
administrator needs.
We were talking about th
2010/3/23 Jérôme Loyet :
> In fact with INI syntax, there is a serious missing cause there is no
> include system shiped with. And with FPM as there is potentialy many
> "vhosts", it's necessary to have an include system to feet all system
> administrator needs.
That was something I brought up to
2010/3/23 Zeev Suraski :
> At 21:43 23/03/2010, Antony Dovgal wrote:
>>
>> > - The config file change, moving from the XML-based php-fpm.conf to
>> > using php.ini (I think some work had started on this, but syntax was
>> > under debate?)
>>
>> We've discussed this many times and I thought it's pre
At 21:43 23/03/2010, Antony Dovgal wrote:
> - The config file change, moving from the XML-based php-fpm.conf to
> using php.ini (I think some work had started on this, but syntax was
> under debate?)
We've discussed this many times and I thought it's pretty clear that php.ini
syntax won't fit in
On Tue, Mar 23, 2010 at 4:09 PM, Michael Shadle wrote:
> On Tue, Mar 23, 2010 at 12:43 PM, Antony Dovgal
> 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
On Tue, Mar 23, 2010 at 12:43 PM, Antony Dovgal 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 requireme
Antony Dovgal wrote:
On 03/23/2010 10:26 PM, Michael Shadle wrote:
- Jerome's put in some statistics functionality, which could be useful
in monitoring, etc. - might be nice to mention in the "features" [I
would include only the JSON output though]
I mentioned it, albeit briefly:
* basic SAP
On 03/23/2010 10:37 PM, Pierre Joye wrote:
> hi Tony,
>
> On Tue, Mar 23, 2010 at 6:25 PM, Antony Dovgal wrote:
>
>>> Does it really need to be separate SAPI? I mean, just replace the old
>>> sapi/cgi
>>> with it? Keep the name 'cgi' though. :)
>>
>> I don't see any need to touch sapi/cgi at al
2010/3/23 Pierre Joye :
> hi Tony,
>
> On Tue, Mar 23, 2010 at 6:25 PM, Antony Dovgal wrote:
>
>>> Does it really need to be separate SAPI? I mean, just replace the old
>>> sapi/cgi
>>> with it? Keep the name 'cgi' though. :)
>>
>> I don't see any need to touch sapi/cgi at all.
>> Keeping both CG
On 03/23/2010 10:26 PM, Michael Shadle wrote:
> - Jerome's put in some statistics functionality, which could be useful
> in monitoring, etc. - might be nice to mention in the "features" [I
> would include only the JSON output though]
I mentioned it, albeit briefly:
* basic SAPI status info (simila
hi Tony,
On Tue, Mar 23, 2010 at 6:25 PM, Antony Dovgal wrote:
>> Does it really need to be separate SAPI? I mean, just replace the old
>> sapi/cgi
>> with it? Keep the name 'cgi' though. :)
>
> I don't see any need to touch sapi/cgi at all.
> Keeping both CGI and FastCGI in one SAPI leads to a
2010/3/23 Michael Shadle :
> On Tue, Mar 23, 2010 at 10:25 AM, Antony Dovgal wrote:
>
>> sapi/fpm and sapi/cgi now have quite different codebase as we've dropped
>> some stuff
>> not pertinent to FastCGI (there might be some leftovers, I'll deal with them
>> later).
>
> Not sure if it's best to
On Tue, Mar 23, 2010 at 10:25 AM, Antony Dovgal wrote:
> sapi/fpm and sapi/cgi now have quite different codebase as we've dropped some
> stuff
> not pertinent to FastCGI (there might be some leftovers, I'll deal with them
> later).
Not sure if it's best to say it here or just post to the wiki
On 03/23/2010 08:15 PM, Jani Taskinen wrote:
> 23.3.2010 18:42, Antony Dovgal wrote:
>> Hello all.
>>
>> Derick (and other people) asked me to create an RFC for FPM describing what
>> it is and why do we need it.
>> Quite.. ahem.. laconic version of such RFC can be found here:
>> http://wiki.php
23.3.2010 18:42, Antony Dovgal wrote:
> Hello all.
>
> Derick (and other people) asked me to create an RFC for FPM describing what
> it is and why do we need it.
> Quite.. ahem.. laconic version of such RFC can be found here:
> http://wiki.php.net/rfc/fpm
>
> I'm open for your questions.
Does
Hello all.
Derick (and other people) asked me to create an RFC for FPM describing what it
is and why do we need it.
Quite.. ahem.. laconic version of such RFC can be found here:
http://wiki.php.net/rfc/fpm
I'm open for your questions.
--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime stat
54 matches
Mail list logo
