Andi Gutmans wrote: > Isn't this all a bit of an overkill? > > Andi
#5 probably is, it's a nicety, but I think the other items are relatively necessary unless you are dependent entirely on Apache, which provides extensive configurability. #1 would allow scripts that only are used on 'command line' to be better configured with seperate ini files. #2 gets rid of needing a bunch of directories for multiple ini files, and is very handy for #4. #3 should be done irregardless (if it isn't already done), otherwise server plugins will only be able to use ini files located in the os directory. If you run both Apache and IIS on the same system, you may well want different ini files for the two. That could be accomplised by different installations as long as the sapi module detects it's own directory. #4 is realy needed for systems running virtual servers under IIS. While you can configure ini in the registry, it's a pain, especially if you want to give users access to edit their own ini file, or you want different extensions loaded for different servers that run under seperate dllhosts. Of course, preferably none of this should be necessary, thus another reason for my dislike of the ini file ;) Shane > > 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
