RE: [PHP-DEV] [RFC] Extension Prepend Files
| From: | François Laupretre | Date: | Thu, 08 Jan 2015 16:22:35 +0000 |
| Subject: | RE: [PHP-DEV] [RFC] Extension Prepend Files | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-80279@lists.php.net to get a copy of this message | ||
Quoting Benjamin Eberlei :
> > 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.
Quoting Pierre :
> So you are saying that people should be forced to use your glue code
> instead of implementing their own when it fits better? I can only
> disagree.
Quoting myself :
>>> What I don't like is the fact to execute PHP code automatically at every
>>> RINIT. I prefer to let the extension free to load its PHP code when its
>>> logic decides it is needed.
We are all talking about PHP scripts but with very different usages :
- Pierre is talking about 'glue code'. From what I understand, this code is used directly
from userspace but optional, and the final user can decide to use alternate code. So, it is
legitimate that usage of this code is under the control of the final user and not to bundle it in
the extension library.
- Benjamin is talking about user-exposed essential extension classes. These MUST be defined at each
request start or the extension loses part, if not all, of its API. His pov is legitimate too. The
only prevention I would have is the overall impact on performance but, if the final user accepts it
knowingly, why not ?
- My use case is slightly more complex. My PHP contains pure 'back-end' features. This
code is used exclusively from the extension C code and does not expose anything to userspace. To
explain my use case to Benjamin, here is an example from the PHK extension : PHK is a package
system. It distributes a virtual file tree. When I need to stat or read a virtual file, the C code
first looks if the required data is present in a cache. If not, it loads the appropriate PHP code
and calls it to retrieve the data from the package file. This PHP code is long, complex, and deals
with many cases and options (virtual file tree, compression, package metadata...). Then, the C code
caches the returned data. The next time the same resource is requested, it is retrieved from the
cache WITHOUT having to load and execute the PHP code. The C code can decide when PHP code needs to
be loaded because it is the only 'user' for this code (pure back-end). I can implement the
complex code in PHP because it is behind a cache, but it is essential, for performance reasons, that
this code is not loaded when everything I need is in cache. I'd prefer to embed my PHP code in
the extension library because I definitely need to keep both codes in sync, and keeping them
physically together is, IMHO, the easiest way to ensure this. Today, the runtime PHP code is stored
in the package itself. It allows to make the extension optional, but with BC issues I wouldn't
have if both codes were stored together.
So, IMO, all 3 usages are legitimate but each of us has something different in mind.
The solution for Pierre's needs is in build/deployment tools and ,maybe, a pair of C macros to
define standard paths (I proposed one, what do you think about it ?).
Benjamin and I would make full use of a generic, easy-to-use mechanism to embed plain files (not
only PHP scripts, any data can fit) in an extension library. Then the extension developer decides
what it loads at each request start. I'll try to build a prototype for this.
Cheers
François