Re: Re: PHP-4.0.7RC1

At 17:13 17/08/2001 +0300, Zeev Suraski wrote:

At 17:05 17-08-01, Cynic wrote:

I'd do this: 4.0.7:

php.ini-standard       basically today's php.ini-dist
php.ini-recommended    basically today's php.ini-optimized
                       + the proposed security related changes
                       what this is exactly I don't know. perhaps
                       only register_globals off

This already exists today (except -standard is still called -dist, as there's no real reason to change it). We may try to encourage people to read php.ini-recommended at the and of the build process, because I fear nobody's looking at it today.

*** That's pretty clear. Maybe we could make a setup script that would write the php.ini for the user depending on the --config_file_path value ? It would propose an automatic setup (either -dist or -recommended) or a manual setup (yes|no,1|0 style). In "we" I don't count myself as I know Perl almost like a (real) camel.

4.1.0:

php.ini-standard       php.ini-recommended as contained in 4.0.7
                       + anything else you think should be there
                       (it can be more "strict" than 4.0.7's rec.)
php.ini-compat         php.ini-standard as contained in 4.0.7

I'm not sure that we can just move to do -recommended version, 4.1.0 or not. The nature of recommendations is that some people accept them, and some do not :) None of the things in the php.ini-recommended file is a clear-cut must-have, and some people will prefer doing without them. We'll have to think about each change separately. Remember that we only use the version change to catch people's attention. It doesn't mean that we can suddenly make PHP much more 'hostile' :)

*** OTOH, maybe PEAR people would like to see some "comfortable" defaults ?

And while I'm at it: can the Powers That Be consider switching the default setting for display_startup_errors to On in either of the ini files? I believe (my experience indicates it) that this would help to lower the confusion in some cases quite a bit: a message instead of just a 500 can change one's day.

There's a good reason for this default setting. A clear message will not only change your day, but also the guy who's trying to hack your site's day :) For example, with display_startup_errors set to on, a request can be easily made that will expose the full path of any scripts on your site. It may make good sense to set it on in the -recommended version, as it's safe in conjunction with display_errors=0 and log_errors=1. Zeev *** I understood that 4.0.7 / 4.1.0 would be a question of what we want next.

If E_ALL brings better code, why not encourage that ? Democracy is good as long as it's evolving. If we encourage a default lax behavior, lax coders we'll have. If we encourage tighter programming, even the novice can cope with it and learn faster, and make less mistakes, etc. Is that too optimistic ? Or am I forgetting the existing code base ? I think that as $HTTP_*_VARS disappear, lots of people will have to change that (Search/Replace + delete the corresponding "global" calls) anyway in order to use the new $_* arrays in future versions. It's probably better to bother people once for good instead of once every version. The purpose of 4.0.* vs .4.1.* should be clear for all : it's a new step and you have to make it. RFC hellekin