Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80360
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <004e01d02d6d$3e745180$bb5cf480$@tekwire.net>
References: <CAEPJdu=2oWiSCQOTkO1g5QDs4NrJwd5H14Jks17qrNu7-eQNVg@mail.gmail.com>
	<CAEZPtU5M_NdtZ-e_48Ce5Rjb1KKHkzDMrqLD5sx-WwDctR7u5Q@mail.gmail.com>
	<001501d02ccc$574a6bf0$05df43d0$@tekwire.net>
	<CAEZPtU73+y4AJ9BfACmYuBe79+Ls-A-yQSZhxUoTi3m8KTQEMQ@mail.gmail.com>
	<000a01d02cf8$ab090130$011b0390$@tekwire.net>
	<CAEZPtU5ShKa9bMUOKsSuKjmEcXQZhsEUWrwNmsj2a_VSKSizEw@mail.gmail.com>
	<003c01d02d58$731d0cc0$59572640$@tekwire.net>
	<CAEZPtU6kerXq9z+i6jtn26JUnLgM1imMXasKD6iH14Q7cvDgow@mail.gmail.com>
	<004e01d02d6d$3e745180$bb5cf480$@tekwire.net>
Date: Sat, 10 Jan 2015 23:21:11 -0800
Message-ID: <CAEZPtU5mVnfhgKqrjbi=uq8Ops8zD-mQLQZepMv2RYtzbh0NsA@mail.gmail.com>
To: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@tekwire.net>
Cc: Dmitry Stogov <dmitry@zend.com>, Sara Golemon <pollita@php.net>, Laruence <laruence@php.net>, 
	Derick Rethans <derick@php.net>, PHP internals <internals@lists.php.net>, 
	Benjamin Eberlei <kontakt@beberlei.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Extension Prepend Files
From: pierre.php@gmail.com (Pierre Joye)

On Sat, Jan 10, 2015 at 11:07 PM, Fran=C3=A7ois 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 m=
init or on the first request and flag them as
>> permanent. Yes, it means we need to change opcache but could be way easi=
er 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 chang=
e to the cache code.
>
> Personnally, if I implemented this, I would distribute a virtual file tre=
e through a stream wrapper. The stream wrapper would be the same for all 'c=
lient' 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 : (d=
irname(__FILE__).'/relative/path'). We just need the stream wrapper to emul=
ate '.' and '..' and the whole range of relative paths is available. This w=
ay, 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 feature=
s 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 danger=
ous features, like include_path or globbing, to 'local' wrappers, and some =
of these wrappers desperately need these features (primarily phar developer=
s 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.



--=20
Pierre

@pierrejoye | http://www.libgd.org