Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:1018
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Wed, 23 Apr 2003 12:13:27 -0700
To: internals@lists.php.net
Message-ID: <593735812.1051100007@[10.0.0.137]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==========593752651=========="
Subject: PATCH Deprecated modules patch.
From: mloftis@modwest.com (Michael Loftis)

--==========593752651==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I've done a small patch (no ./configure option at this time) that allows 
you short-circuit loading of modules.  mw_deprecated_extensions is the new 
config variable, set as a PHP_INI_SYSTEM restriction level.  It has a 
little bit of OS specific code, only tested on Linux, should work on any 
Unix though.  Not tested under Win32 and probably won't work there.

In order to get it to work at this point you need to #define 
MW_DEPRECATED_EXTENSION

I don't know that this is the best way to do this but it seems that if the 
team wants to keep moving modules into the core we need to make a method 
for large web hosts (like my employer Modwest here) to be able to make a 
list of modules to not try to load so as to make moving between versions 
somewhat more transparent.

The patch against 4.3.1 is attached, I welcome any comments or suggestions 
for improvement.

I do fully agree with Sascha that what is *really* needed is something else 
entirely, but this is a stop-gap measure that we're going to use in the 
meantime.  Extensions should be able to inform of their status at any given 
time.

This is a hack but until such time that a better method is employed it 
would be nice to have something like this.  I'll be making further changes 
so that PHP loads an extra INI file specifically just so we can put the 
mw_deprecated_extensions directive in a file by itself and thus not have to 
touch everyone's INI files here.

For us though compiling more and more into the core statically poses a 
performance and scaling problem.  If we can save startup time we always do, 
which is part of the reason we use dynamic extensions, instead of compiling 
in everything anyone would/might want we make them as modules.

--
Michael Loftis
Modwest Sr. Systems Administrator
Powerful, Affordable Web Hosting
--==========593752651==========--