Re: [RFC] Extension Prepend Files

On Sat, Jan 10, 2015 at 11:07 PM, François Laupretre <francois@tekwire.net> wrote: > De : Pierre Joye [mailto:pierre.php@gmail.com] > >> Say we do support builtin scripts, an opcache will simply load them on minit or on the >> first request and flag them as >> permanent. Yes, it means we need to change opcache but could be way easier than trying to >> hack the engine to support >> persistent Opcodes without ending with ... an opcache. > > OK. Agree. I just didn't understand how it was possible without any change to the cache > code. > > Personnally, if I implemented this, I would distribute a virtual file tree through a stream > wrapper. The stream wrapper would be the same for all 'client' extensions. The fact to > emulate a file tree would allow PHP scripts to reference each other using a path similar to what we > do in packages : (dirname(__FILE__).'/relative/path'). We just need the stream wrapper to > emulate '.' and '..' and the whole range of relative paths is available. This > way, the script executes in an environment as familiar as possible. To avoid conflicts, each > extension would have a separate root dir, something like > '<protocol>://<extension-name>/'. For a pure builtin script for an extension point of view, I am not in favour of allowing multiple files or add streams. The impact will be too big in comparison to in-memory, cache&check only once, scripts. Starting to redo phar for extension builtin scripts sound like an even bigger can of worms. > Off topic: I'd like to write a PHP7 RFC to extend the file system features whose behavior > remains different for plain files and for stream wrappers. As most RFCs I write these days, this is > an old subject but it was refused for security reasons, as there was no way to distinguish a > 'remote' stream wrapper from a 'local' one. Now, the is_url flag allows to > restrict dangerous features, like include_path or globbing, to 'local' wrappers, and some > of these wrappers desperately need these features (primarily phar developers and me, actually :). If > you find it crazy, please tell me before I write something more elaborate. Good idea, and the stream APIs need a cleanup as well (see the other discussions about that too). One key point btw: portability. Adding non portable features add more pains than gains. -- Pierre @pierrejoye | http://www.libgd.org