Jani Taskinen wrote:
> Anyway, now I see that there really is good reason having that
> version (PHP_#ext#_API_NO ?) after all. And having that..we should
> propable start moving those extensions one by one into PEAR?
do we have the infrastructure in PEAR for C code yet ?
> Maybe we could then roll out two packages, one for core and one for
> the extensions?
this wouldn't really solve the problem as you still have different
versions of packages at least in the extension part while it adds
more complexity leading to users trying to get core version x together
with extensions version y where x and y do not fit
> And btw. Why not have a function in PHP core that can be used to get the
> desired extensions remotely from pear.php.net? If we have a
> PHP_#ext#_API_NO, running a 'update_php_extensions()' would
> go and grab the updated (if the extension HAS been updated) one..etc..
nice idea, but once again: we are talking about C-code and shared
libraries here, how do you get a system to compile things automaticly
from within a webserver process (which usually does not have the access
rights needed to update things in the filesystem) and how do you
force php to exchange .so versions on the fly, especially in a multi-
threaded server, while keeping php and the server running ?
--
Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
