Isn't this all a bit of an overkill? Andi
At 12:18 02/05/2002 -0700, 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). > >Shane > > > >-- >PHP Development Mailing List <http://www.php.net/> >To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
