There's no reason to not put in the bin-dir solution now. I just would like to see an eventual full solution to the issue.
Zeev Suraski wrote: > 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
