> De : Pierre Joye [mailto:pierre....@gmail.com]
>
> ... here,
> it is proposed to bundle scripts that will be executed at runtime like any
> other script, except that nothing can be done with them, not even disable
> them if not required (like using its own glue codes).

I agree. Bundling scripts in extensions to execute them at each RINIT is, IMO, 
not a good idea (mostly for performance reasons and lack of control, as you 
note), but I keep thinking that a mechanism to embed PHP scripts in extensions 
and make them available via a common stream wrapper can be useful. What I don't 
like is the fact to execute them automatically at every RINIT. I prefer to let 
the extension free to load its PHP code when its logic decides it is needed.

> Pickle integration is almost finished, that solves your worries about 
> composer and pecl extensions.

Both mechanisms can coexist. They are not incompatible and probably fulfill 
different needs.

You are asking for a standard path for plain files linked to an extension. As 
putting the shared library and plain files together is not a good idea, what 
about something like this :

<php-install-prefix>/lib/php/extensions/php/<extension-name>

A C macro can be defined to provide the path to the extension C code, in order 
to avoid hardcoding it (this way, it could be modified in the future).

At install time, we could say that every files under 
<extension-source-dir>/php/install, if this dir exists, are installed there.

It is just an example but does it correspond to the mechanism you were thinking 
about ?

What is not clear to me is the question of packaging/versioning/deployment. If 
you consider the PHP glue code is modified more often than the C code, which 
will be the most frequent case, how do you version/distribute partial packages 
? or do you deliver 2 packages with independent versioning and dependencies 
together ? In this case, should we define a versioning convention for both 
packages ?

Regards

François



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to