Personally I don't care what is the default extensions are as long as
I can change them.
(I have written this email several times, but never sent it or I may
have, but don't remember if so sorry if repeating).
Here are my problems with extensions:
A) Extensions that change the core code when built statically.
I think this should not be possible! 4.3 takes care of this problem
with mbstring and I don't know of any others, but that doesn't mean
it can't happen again.
B) Extensions that can only be built statically or while PHP is building.
4.3 version of sessions fixes this (I think), but you can't build
session shared with
out mm in version 4.2.x (via phpize)
Any/All extension should have to pass a test of:
1) Can it be built and work statically into PHP
2) Can it be built shared while building PHP
3) Can it be built shared by phpize, configure, make method.
Also can I do steps 1-3 with any of its options enabled or disabled
If it includes extra sources (xml -> expat, xmlrpc -> libxmlrpc)
1) Can it be built statically into PHP with included library
2) Can it be built statically into PHP with a shared library
3) Can it be built with PHP shared with included library
4) Can it be built with PHP shared with a shared library
5) Can it be built shared by phpize, configure, make method with
included library.
6) Can it be built shared by phpize, configure, make method a shared library.
Also can I do steps 1-6 with any of its options enabled or disabled
Also, just because they configure and build a .so files doesn't
mean they work and have the right dependences. That should be tested
as well.
If all these things are meet then somebody can build a bare bones
PHP and build extensions as needed. Currently not all extension can
do this.
It would be nice to make the above a requirement to get into the
ext directory and recommended for things in pear/pecl.
That's just my opinion, I could be wrong.
Brian
BTW, Thanks to Jani Taskinen for putting up with me while fixing a
few extensions.
At 10:19 PM +0100 9/2/02, James Cox wrote:
> > Unfortunately we don't live in a perfect world where
>> sysadmins know how to read and listen to their users
>> requests. That's why mysql for example is enabled by default.
>> (or that's the main reasoning behind it at least)
>>
>> And we can't educate people or force them to anything either.
>>
>> Maybe we should add a general '--disable-all' option?
>>
>
>i'm +1 for that if it means that first it disables everything, and then you
>enable stuff bit by bit...
>
>i still don't see why we shouldn't just disable everything by default and
>write a 'default configure' script...
>
> -- james
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
