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