Re: config.w32.h...registry configuration

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 :)"