2009/12/9 Olivier Hill :
> Hello Michael,
>
> Are you talking about this?
>
> --with-config-file-scan-dir=...
>
> http://www.radwin.org/michael/blog/2006/07/phpini_hacks_withconfigfil.html
oh, duh - I guess I am. Except it would be nice to have it inside of
php.ini itself and not defined at compil
Hello Michael,
Are you talking about this?
--with-config-file-scan-dir=...
http://www.radwin.org/michael/blog/2006/07/phpini_hacks_withconfigfil.html
Regards,
Olivier
2009/12/9 Michael Shadle :
> 2009/12/9 Jérôme Loyet :
>
>> is there a way to include files ?
>> include /etc/php-fpm/*.conf ? w
2009/12/9 Jérôme Loyet :
> is there a way to include files ?
> include /etc/php-fpm/*.conf ? with one file per worker for example ?
>
> I think adding include to ini should not be a problem if it's not already
> done.
I would love to see the php ini file support includes like MySQL does.
Probab
Le 9 décembre 2009 23:25, Tjerk Anne Meesters a écrit :
> Hi,
>
> ini files can be split, so it doesn't all have to be inside one
> monolithic php.ini
is there a way to include files ?
include /etc/php-fpm/*.conf ? with one file per worker for example ?
I think adding include to ini should not b
Hi,
ini files can be split, so it doesn't all have to be inside one
monolithic php.ini
I agree that repetition doesn't look nice; it would be nice to have
something like:
[fpm.worker.worker1]
listen = 127.0.0.1:1900
uid = webservice
Etc.
Didn't really pay attention to those pool settings, but
Le 9 décembre 2009 20:56, Michael Shadle a écrit :
> 2009/12/9 Jérôme Loyet :
>
>> do you mean that it would be included in the global php.ini file ? I
>> never imagine that. For me it's an independant conf file
>> (/etc/php-fpm.conf for example).
>
> correct. I don't see any reason for a differen
2009/12/9 Jérôme Loyet :
> do you mean that it would be included in the global php.ini file ? I
> never imagine that. For me it's an independant conf file
> (/etc/php-fpm.conf for example).
correct. I don't see any reason for a different configuration file anymore
--
PHP Internals - PHP Runtime
Le 9 décembre 2009 20:44, Michael Shadle a écrit :
> I see it more like:
>
> fpm.global.daemonize = yes
> fpm.global.error_log = /var/log/php-fpm.log
>
> or skip global:
>
> fpm.daemonize = yes
> fpm.error_log = /var/log/php-fpm.log
>
>
> for each worker pool:
>
> fpm.worker1.name = pool1
> fpm.wo
I see it more like:
fpm.global.daemonize = yes
fpm.global.error_log = /var/log/php-fpm.log
or skip global:
fpm.daemonize = yes
fpm.error_log = /var/log/php-fpm.log
for each worker pool:
fpm.worker1.name = pool1
fpm.worker1.address = 127.0.0.1:9000 ; or socket
fpm.worker1.uid = www-data
fpm.wo
Le 9 décembre 2009 19:17, Michael Shadle a écrit :
> 2009/12/9 Zeev Suraski :
>
>> We should be using INI unless there are compelling reasons against it, now
>> that this project becomes a part of the PHP source tree. As far as I can
>> tell there are no such compelling reasons and it can actuall
2009/12/9 Zeev Suraski :
> We should be using INI unless there are compelling reasons against it, now
> that this project becomes a part of the PHP source tree. As far as I can
> tell there are no such compelling reasons and it can actually map quite
> nicely into INI, hence, that's what we shoul
At 19:44 09/12/2009, Jérôme Loyet wrote:
So let have the question another way:
Do we keep XML or do we switch to something else ? If so, which format ?
I and some others think xml is not appropriate here because of the
complexity. So I do think there is a need to change.
INI or other ?
INI is u
On 09.12.2009, at 20:44, Jérôme Loyet wrote:
> Le 9 décembre 2009 17:16, Pierre Joye a écrit :
>> hi,
>>
>> 2009/12/9 Jérôme Loyet :
>>
> We already discussed pros/cons of the two solutions. But why don't we
> allow several syntaxes ? And let the end user to choose the better one
>
Le 9 décembre 2009 17:16, Pierre Joye a écrit :
> hi,
>
> 2009/12/9 Jérôme Loyet :
>
We already discussed pros/cons of the two solutions. But why don't we
allow several syntaxes ? And let the end user to choose the better one
for its need ?
>>>
>>> No. Thank you.
>>> EOD
>>>
>>
>> a
Hi!
I think multiple syntaxes is an unnecessary complication, and they don't
serve any useful purpose - neither of those syntaxes allow you to do
something important that others don't.
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...
hi,
2009/12/9 Jérôme Loyet :
>>> We already discussed pros/cons of the two solutions. But why don't we
>>> allow several syntaxes ? And let the end user to choose the better one
>>> for its need ?
>>
>> No. Thank you.
>> EOD
>>
>
> and why of that ? Why is it already EOD wihtout arguing ? php-fpm
Hi,
I know little aobut FPM but:
On Wed, 2009-12-09 at 15:55 +0100, Jérôme Loyet wrote:
> We already discussed pros/cons of the two solutions. But why don't we
> allow several syntaxes ? And let the end user to choose the better one
> for its need ?
No. Several syntaxes makes testing harder, is
Le 9 décembre 2009 15:57, Antony Dovgal a écrit :
> On 09.12.2009 17:55, Jérôme Loyet wrote:
>> Hi guys,
>>
>> I start a new thread about the syntax that should be used in php-fpm
>> to replace xml.
>>
>> As discussed before, there is different point on view on this subject:
>> - INI to stay in th
On 09.12.2009 17:55, Jérôme Loyet wrote:
> Hi guys,
>
> I start a new thread about the syntax that should be used in php-fpm
> to replace xml.
>
> As discussed before, there is different point on view on this subject:
> - INI to stay in the PHP philosophy / practicals
> - nginx because it was the
Hi guys,
I start a new thread about the syntax that should be used in php-fpm
to replace xml.
As discussed before, there is different point on view on this subject:
- INI to stay in the PHP philosophy / practicals
- nginx because it was the will of the original authors
We already discussed pros/
20 matches
Mail list logo
