Perhaps the searching could be controlled by a compile-time setting? On
in the Windows binary builds, but it is much more trivial these days to
compile your own.
Yet, my question is this: how often will PHPRC and the registry be set
for CGI, and neither have ini files? That seems pretty unlikely to me.
So, I think the more likely case is 4 directories to be searched. Most
of the time the ini file will be found in WINDOWS or in the binary
directory, which means the most common use case is 3 directories to search.
Anyway, it could easily be documented that - for best performance -
you'd want to set PHPRC or put your ini files in the binary's directory.
Or pass the -c option.
Also, imho, just because paths to PHP might be in the registry when
using IIS does not mean system administrators prefer to use the registry
over ini files. I would tend to think this is largely untrue.
-[Unknown]
-------- Original Message --------
-----Original Message-----
From: Richard Quadling [mailto:[EMAIL PROTECTED]
Sent: Monday, August 07, 2006 11:52 AM
To: Dmitry Stogov; PHP Developers Mailing List
Subject: Re: [PHP-DEV] Supporting version specific INI files
as well as SAPI specific INI files.
Dmitry,
We seem to be on entirely different sides of the fence.
I've answered your comments below.
If I have not explained myself well enough, then so be it,
I'll abide by the decision of the developers.
I DO thank you for the consideration that you've given and I
hope that just because I disagree with you, you don't dismiss
any comments I make on this or other topics.
Regards,
Richard Quadling.
On 07/08/06, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
I see several problems with version specific ini files
1) PHP might need to check tens of files before opening
/etc/php.ini.
Currently there are 2 generic files being scanned for
(php.ini and php-sapi.ini). I'm extending this to be
phpx-sapi.ini, phpx.y-sapi.ini, phpx.y.z-sapi.ini and
phpver-sapi.ini. This is only an extra 4 files max.
These files are searched in several directories.
PHPRC:regestry:binary dir:current working dir:default location(windows and
windows /system32)
6 direstories in worst case.
So with your solution we will look for 6 files in 6 directories.
36 files in worst case.
This is not a big problem for ISAPI or apache module, but might be a problem
for CGI.
2) Ther is an ambiguity in naming schema. If we have
php-5.2.0-apache,
which file should we prefer php5.ini or php-apache?
My code only extends SAPI AND version specificness. In my
context, php5.ini is NOT searched for. It HAS to be SAPI
specific as for windows you cannot control the exact ini file
any other way. Not JUST version as CLI and ISAPI require
different error reporting (just 1 setting of many). So,
assuming php-5.2.0-apache is running then the files I would
expect to look for would be php5.2.0-apache.ini,
php5.2-apache.ini, php5-apache.ini, php-apache.ini and
finally php.ini. The purpose of this whole thing is to allow
2 or more different versions of PHP using the SAME SAPI to
run side-by-side. php4-isapi.ini, php5-isapi.ini,
php6-isapi.ini, and php5-cli.ini. I initially only wanted
major version, but comments where made about differences in
v5.1 and v5.2, so I extended this to be the complete version
(including the -dev, RCx, etc).
You are right here. Your schema will work.
I just thought about ini files with version information but without sapi
suffix.
3) Which startage should we use for ini file search in multiple
directories. Check all names in each directory or check
each name in
all directories?
Whatever happens currently for php-sapi.ini and php.ini
should work for the extension. I'm NOT changing __HOW__ we
find an ini file, just __WHAT__ ini files we look for. If the
current multiple directory logic says look for sapi specific
files in all directories first and then look for php.ini in
all directories, then this is simple extended to look for the
extra ini files. If the logic is to look for all ini files
per directory then that is extended.
This __HOW__ is a problem right now too.
If we have php.ini in "binary dir" (see (1)) then matched php-sapi.ini from
"current working dir" will not work.
I prefer specify php.ini explicitly and I made several
patches to do
it. These patches didn't affect PHP/ISAPI and idea with
registry was
good.
But this FORCES me to use the registry when I've not needed
to. PHP __CURRENTLY__ uses INI files on windows as the
__DEFAULT__ mechanism. I'm just extending this. The registry
is optional and cannot be centralised. If PHP runs from a
share, then you have the have the registry set on EVERY
machine which can run PHP.
Do you setup IIS to run PHP from share?
Then you have to record path to php in IIS metabse.
How is it different from storing path in the registry?
Now I don't see a big reason in version specific files.
Portability. I can take the settings from 1 setup to another.
I can copy the settings for a new version. I can compare
settings a lot easier. And I don't need to use the registry
for anything. Even with the registry, I am unable to
specifically name the ini file. All I can do is supply a path
to the location of the ini file.
I am agree here. This probably should be corrected.
I then have to have multiple
INI files with the same name and no indication of there
version. THIS is more confusing. And finally the registry is
purely local machine only. I am CURRENTLY able to run PHP via
a share (why? Because I can!) and I don't need any additional
You can also try to use PHPRC environment variable.
Dmitry.
Thanks. Dmitry.
--
-----
Richard Quadling
Zend Certified Engineer :
http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
--
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
