On 09/02/02, "James Cox" <[EMAIL PROTECTED]> wrote: > But you see, it's not really all that solid. It needs more work (hence this > apparent development outside of php.net).
But it *is* VERY stable in the default configuration. > All I am saying is that we should > disable it by default in current releases. For PHP5, we should have proper > mbstring support that should probably also be transparent; by that I mean I > see no reason for it not to be as standard functionality rather than an > extension, if that is necessary. The transparent encoding style options - including that of the sessions should *never* be enabled by default precisely because they are transparent and cause "unexpected behaviour" for people that haven't read the docs. > I will let Phil know that he can update his errata to just removing the one > compile option -- however, he demonstrates a valid point: unexpected > behaviour sucks. This includes the building of modules that you don't need. Umm, but the behaviour was only unexpected because he enabled an option without reading the docs to find out what it does. (regardless of the fact that there was a slight bug: the very next bug report would be along the lines of "PHP is changing encodings automatically"). > if it were me, i'd rather just be able to build the bare-bones PHP binary > without an extensions, and compile others in as i needed them. By enabling > extensions by default, what you end up doing is increasing the size of the > end product... now that, in most cases, doesn't make a difference, however > for scenarios where you have very little space to play with... having > extensions compiled in by default that you don't know about sucks. But in that situation, you would be paying close attention to what you were building anyway. > As I see it, PHP was designed with speed and simplicity in mind. Having the > burden of a large number of extra modules compiled in by default doesn't > help, and deviates from this path. No, you can always disable those extensions. The default extensions were *voted* in for a reason. > Compiling modules by default which are > buggy just compounds the problem. Yes, but the bug was only present in an advanced optional feature that would cause "unexpected behaviour" for non-mbstring aware people anyway. *and it has already been fixed a number of weeks ago* As I've said, mbstring is very stable in it's default configuration - the codebase has been around for years and tested to death by a very dedicated i18n team *in production*. The "development" you keep referring to is part of a streamable filter *add-on* that does not change the existing code that people rely on. Why don't you test the current CVS to see if it still has a problem, if it does, lets fix it. Please don't take a step backwards by disabling this extension by default just because you are afraid that people can abuse advanced options. --Wez. -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
