Re: Latest commit -- depreciation of call_user_method()

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 hartmut@six.de http://www.six.de +49-711-99091-77