Hi Derick,
I see another issue after reading this, and that is that it makes it
much harder for users to depend on specific extensions just being always
available by default. It's important for application distributers to
have this core set of extensions to rely on. It's annoying enough that
some distributions (gentoo, freebsd) already use --disable-all and their
users then bugging us (or me) with "you should check that SPL is enabled
in your code".
Well, you should, while it's possible to disable it!
Consider a distribution that has _only_ the essentials. Consider also a
relatively small bundle of PECL extensions that ships alongside it. Say we
classify them: everything that currently ships with core would be class A1
or whatever, as would anything else in PECL that is stable and considered
likely to be useful to a wide range of users. Anything in that bundle is
"recommended", and we make it very plain to sysadmins that they should
install any of that bundle supported by their system. It includes things
like (most) PDO drivers, SOAP, sqlite, zip, curl, json... all things that
are currently shipped with the core but not necessarily (under doze at
least) enabled by default. We educate PHP users to insist on 'the A1 pack'.
We also make it _possible_ to operate PHP without 'the A1 pack', but I do
just mean 'possible'. (In other words it should be possible to write a basic
website using PHP as it comes, without adding or enabling anything.)
If everything in PECL were classified, it'd be much easier for people to
figure out what to load and when. A simple 'justification' line alongside
the classification would be immensely helpful, assuming the info in
package.xml is made obvious via the installer. You'd need a few extra
sections in package.xml, e.g:
<version>2.0</version>
<status>stable</status>
<classification>
<rank>A2</rank>
<reason>specialist interest</reason>
</classification>
<maintenance>
<level>active</level>
<lastfix>10/01/08</lastfix>
<bugsopen>5</bugsopen>
</maintenance>
That tells users and sysadmins alike everything they need to know about that
extension and allows them to make an informed decision about installing it,
or not, as the case may be. Some of that info could even be autogenerated...
Anything _not_ in 'the A1 pack' would need to be downloaded individually,
via a system we don't have yet (again, speaking as a Windows user). Another
thing would be to offer downloads by classification, e.g. 'pecl install A1'.
- Steph
regards,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
