Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80321
Return-Path: <francois@tekwire.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 54631 invoked from network); 10 Jan 2015 11:55:44 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 10 Jan 2015 11:55:44 -0000
Authentication-Results: pb1.pair.com header.from=francois@tekwire.net; sender-id=softfail
Authentication-Results: pb1.pair.com smtp.mail=francois@tekwire.net; spf=softfail; sender-id=softfail
Received-SPF: softfail (pb1.pair.com: domain tekwire.net does not designate 212.27.42.2 as permitted sender)
X-PHP-List-Original-Sender: francois@tekwire.net
X-Host-Fingerprint: 212.27.42.2 smtp2-g21.free.fr  
Received: from [212.27.42.2] ([212.27.42.2:18528] helo=smtp2-g21.free.fr)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 6E/90-48183-E3311B45 for <internals@lists.php.net>; Sat, 10 Jan 2015 06:55:43 -0500
Received: from moorea (unknown [82.240.16.115])
	by smtp2-g21.free.fr (Postfix) with ESMTP id C3FBB4B01F1;
	Sat, 10 Jan 2015 12:53:35 +0100 (CET)
Reply-To: <francois@tekwire.net>
To: "'Pierre Joye'" <pierre.php@gmail.com>,
	"'Benjamin Eberlei'" <kontakt@beberlei.de>
Cc: "'PHP Internals'" <internals@lists.php.net>
References: <CAEPJdu=2oWiSCQOTkO1g5QDs4NrJwd5H14Jks17qrNu7-eQNVg@mail.gmail.com> <CAEZPtU5M_NdtZ-e_48Ce5Rjb1KKHkzDMrqLD5sx-WwDctR7u5Q@mail.gmail.com>
In-Reply-To: <CAEZPtU5M_NdtZ-e_48Ce5Rjb1KKHkzDMrqLD5sx-WwDctR7u5Q@mail.gmail.com>
Date: Sat, 10 Jan 2015 12:55:33 +0100
Message-ID: <001501d02ccc$574a6bf0$05df43d0$@tekwire.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKBrOMj1TuM8+kkOgWpn3PeY833kwH7Ko95m0ZdpDA=
Content-Language: fr
X-Antivirus: avast! (VPS 150110-0, 10/01/2015), Outbound message
X-Antivirus-Status: Clean
Subject: RE: [PHP-DEV] [RFC] Extension Prepend Files
From: francois@tekwire.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=)

> De : Pierre Joye [mailto:pierre.php@gmail.com]
>
> A proof of concept, IRC log, I am lazy :)
>=20
> <Pierre> benjamin, Derick
> https://gist.github.com/pierrejoye/ce4867a5eaabffa71df4
> https://gist.github.com/pierrejoye/0859e3702ceb3bb652b6
> https://gist.github.com/pierrejoye/544e60d8994094c55583
> <Pierre> too slow internet for a fork & PR
> <Pierre> but it works now. Add PHP_BUILTIN_SCRIPT(date,
> PHP_EXT_DIR(date)/date.php) to config.m4, and call manually
> zend_execute_script in RINIT, could be easier to do it in a register
> function, inside MINIT and let the engine do it on RINIT, actually
> cleaner, but this patch is only a prrof of concept to play with

Thanks for this. I thought you were opposed to bundling PHP code in =
extension... :)

I prefer the solution where the extension execute the script(s) in RINIT =
or at any time, instead of registering scripts in the core and let the =
core trigger script execution. The main reason is that executing EVERY =
scripts in RINIT is just one use case among many others.

The problem I see with zend_execute_string() is the relationship with =
opcode caches, because the filename you provide is not a real filename. =
When an opcode cache receives such a name, it will analyze it as a valid =
plain file name and it will try to stat() it for mtime, which will =
probably fail... Actually, the opcode cache has no way to understand =
what's going on here. That's why I proposed to use a stream-wrapper. It =
would imply a registration mechanism to ensure path unicity but it would =
allow opcode caching. And opcode caching is most important here, =
especially for code executed systematically at RINIT time.

Cheers

Fran=C3=A7ois