On Mon, 2014-02-17 at 15:02 -0600, Ralph Schindler wrote:
> I think the idea here is to be able to have per-project extension
> dependencies, as you said, with composer. This would be ideal in a way
> for the ecosystem to vet extensions before inclusion in core. But
> currently, unless you own the system, extensions are extremely
> inaccessible to gain any real momentum.
Right, but this isn't a trivial problem. We must ensure that
- extensions load quickly (right now we can have relatively
expensive MINIT code)
- extensions survive loading at run time (some extensions, like
session, eventually send HTTP headers, many won't handle
"class/function already defined" errors well)
- we don't run into issues in threaded environments (as long
as we support those)
- we can properly unload and clean up (some extensions mess with
internal data structures, sometimes the OS has issue with releasing
all symbols etc.)
- we don't open too much of a pandorra's box in regards to security
(if we restrict it to extension_dir it is useless for the composer
case, if not we provide a tool to bypass all of PHP's blocking
mechanisms)
- ...
I think it is great to do, but a proper solution is not a small project
but might require a revamp of many APIs.
And I want to remind about my typical opinion: We should try to require
as little extensions as possible and do as many things as possible (in a
usable way) in userland. If we spend time on making PHP faster we reduce
the need for extensions even more.
johannes