> -----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
