[EMAIL PROTECTED] wrote: [...]
>
>>A solution might be to add a new php_module_startup_ex(...) function
>>with the right parametes, and let php_module_startup() be a wrapper
>>around it.
>>At least this would keep existing SAPI-modules working:
>>
>>
>>/* {{{ php_module_startup
>> */
>>int php_module_startup(sapi_module_struct *sf, zend_module_entry
>>*additional_modules, uint num_additional_modules)
>>{
>> return php_module_startup_ex(
>> sf, &additional_modules, num_additional_modules );
>>}
>>
>>
>>/* {{{ php_module_startup_ex
>> */
>>int php_module_startup_ex(sapi_module_struct *sf, zend_module_entry
>>**additional_modules, uint num_additional_modules)
>>{
>> /* old php_module_startup() body here */
>>}
>>
>>What do you think?
>
>
>
> My opinion...your solution clearly achieves your desired goal.
> However, I don't like the idea of leaving php_module_startup with
> a broken interface. Since only one module would work, the
> num_additional_modules param is misleading. I'd rather fix
> the bug and have folks patch their code to the new faceYou are right. Having a clear interface is probably more important than short-term reduction of work for a few developers.
> (there ain't that many callers, and it's a trivial fix). > Course, I have no authority in the matter ;-)
> Additionally, it is strange to me that we can't call > php_startup_extensions() at app init time after having called > php_module_startup(). But I don't understand the engine design > enough to know if that is prudent.
Yup. A useable php_startup_extensions() would sure be nice. Currently a working php_module_startup() would be sufficient for me, though ;-)
> > NOTE: I think it is also possible that if you add your custom > extension to the php/ext directory that the build scripts will > automatically pickup your extension and add its zend_module_entry > to the generated main/internal_functions.c file. Checkout > http://www.zend.com/apidoc/zend.build.php for more info.
In my case, the PHP extensions are part of a bigger picture and recompiling PHP would not fit very well in existing build processes.
We are uing PHP to provide a web-based interface to a server software written in C++. So the "core part" is the C++ software here...
Anyway, is there anything I can do to get this fixed in CVS? Would a patch have a chance to be applied?
Regards, Norbert
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
