On Wed, Jan 7, 2015 at 11:14 PM, François Laupretre <franc...@tekwire.net> wrote:
> > 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. > To be honest, I don't see the use case of shipping optional PHP code inside an extension. As the user of an extension I want all the functions/classes to be available all the time, no matter if the extension developer wrote everything in C or in PHP. For optional code there is Composer/PEAR/php include path, this is already a solved problem. > > 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 > > >
