Re: Supporting version specific INI files as well as SAPI specific INI files.

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:rquadling@googlemail.com] 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 <dmitry@zend.com> 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&amp;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