On Sat, Jan 10, 2015 at 11:07 PM, François Laupretre <franc...@tekwire.net> wrote: > De : Pierre Joye [mailto:pierre....@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
