> De : Pierre Joye [mailto:pierre....@gmail.com]
> 2. We have no easy way to actually release and deploy adhoc scripts, > used by a given extension > > For 2., it is one of the thing I can imagine implementing in pickle. > Or even better add it a s part of the build scripts and macros. Either > will work, even for binary install on windows f.e.. I would really > like to define a clear location relative to the extension directory. > This location will be used by this new feature, if implemented. I also > think that it should be either part of the current prepend setting, by > default and system only, or another setting. What I really consider as > a bad practice is any kind of bundling scripts in the extensions, that > will be a real pain to maintain and it opens some unknown can of > worms. Distros may also prefer to have that script outside the > extension, easier for cherry picks update when necessary (f.e. > security fixes). I am sorry to say that but, with all due respect, I have a totally opposite opinion. IMHO, this PHP code (and any other data we want to embed) is an integral part of the extension. A compiled extension is a consistent piece of code, it is contained in a single file and should not be split to separate files. The first reason is that, if we consider a released extension as a conceptual unit, the best way to protect its integrity is to store it as a single file. Storing it as separate files brings a lot of potential issues : files can be renamed, deleted, etc. Offline tools like composer can take care of integrity but, from a final user pov, it will never be as clear as a single file (.so for extensions, or package for PHP software). The second reason, more important, is about inter-communication between C and PHP. I understand the pov : it is easier to allow distros to upgrade an extension's PHP code without upgrading the C code. But, if we consider the PHP code as an integral part of the extension, this should be avoided, as C and PHP code need to be kept in sync. If you allow upgrading the PHP code only, you must consider them as two separate pieces of code and, so, consider BC in the way they communicate together. This is a perfectly valid scheme, but, in this case, this PHP code is not part of your extension anymore, it is a separate software with its own version/release numbering, which communicates with your extension. If distros could cherry-pick the C files they want to upgrade, depending on the features they want to provide, would you be ready to keep BC between all your C files ? The same if libc was distributed as a bunch of individually-upgradable files, each defining a function, with consistency ensured by metadata and an offline tool. So, to summarize my opinion : if an extension writer wants to distribute part of his code in PHP and if he wants this code to be upgradeable in an independent way, he must distribute them as an independent software package, not as part of the extension. The whole code to consider as part of an extension, whatever the language, must be kept in sync. And the best way to achieve this is to store it in a single file. Regards, François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
