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
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
