IMHO, the enemy of the good is the better. We can implement the binary-dir solution in no time, and it covers >95% of the problems easily, but instead we'll be discussing perfect solutions and end up doing nothing :)
My 2 agorot. Zeev At 08:03 03/05/2002, Markus Fischer wrote: > Hi, > > but including other INI files at this stage is only of real > advantage if we can also conditionally include it, no? Like, > depending on the version too. > > How about looking for the version number in the filename too > first, e.g.: > > php-apache-4.2.1.ini > php-apache.ini > php.ini > > ? > > This way it's even more less pain to have different versions > installed. > > - Markus > >On Fri, May 03, 2002 at 06:54:41AM +0200, Stig S. Bakken wrote : > > On Thu, 2002-05-02 at 21:18, Shane Caraveo wrote: > > > Zeev Suraski wrote: > > > > Does anybody have an opinion about this? > > > > > > Of course! ;) > > > > > > ini search order > > > 1. PHP_BIN_DIR (\php\) > > > 2. OS_DIR (\winnt\) > > > > > > To fix the ini issue we need more than just this. The best I can come > > > up with right now is: > > > > > > 1. implement bang line parsing. This way, a specific script can define > > > what ini file it wants to use. It should only be available in CGI/CLI > > > systems. > > > > > > 2. add support for -c to use filenames in addition to paths. This way > > > a single directory can contain multiple different config files. > > > > > > 3. have sapi modules (dll's) detect their directory so that server > > > modules can correctly define where the ini file is for a particular > > > installation. > > > > > > 4. For web servers, allow ini filenames to be php-domain.com.ini (or > > > something like that) and have sapi modules look for that first if > > > SERVER_NAME is available. > > > > > > 5. Implement 'override' ini files, which basicly behave the same as > > > .htaccess. Use of these is settable in the 'global' ini file. They > > > exist in the same directory as the script itself, and are read > > > recursivly through the parent directory structure to some root (web > > > root). This of course would be cached in persistent systems, CGI/CLI > > > users would probably not want to use this feature. > > > > > > Some of the above will rely on the OS security being configured > > > correctly so that people cannot access each other's ini files, but that > > > is not the responsibility of PHP to handle (though it could be > > > documented to some extent). > > > > I think we should add: > > > > 6. Implement "include_ini" directive > > > > 7. Look for php-<SAPI>.ini first, and php.ini if not found (this may > > double the disk activity, if that's acceptable). > > > > - Stig > > > > > > -- > > PHP Development Mailing List <http://www.php.net/> > > To unsubscribe, visit: http://www.php.net/unsub.php > >-- >Please always Cc to me when replying to me on the lists. >GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc >"Mind if I MFH ?" "What QA did you do on it?" "the usual?" "ah... none :)" -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
