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@[...].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@[...].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
> >
> >

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php