Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:80279 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 60056 invoked from network); 8 Jan 2015 16:22:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Jan 2015 16:22:46 -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:24953] helo=smtp2-g21.free.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C3/85-21915-2DEAEA45 for ; Thu, 08 Jan 2015 11:22:46 -0500 Received: from moorea (unknown [82.240.16.115]) by smtp2-g21.free.fr (Postfix) with ESMTP id 8A6384B0259; Thu, 8 Jan 2015 17:20:41 +0100 (CET) Reply-To: To: "'Pierre Joye'" , "'Benjamin Eberlei'" Cc: "'Derick Rethans'" , "'PHP internals'" , "'Sara Golemon'" , "'Stanislav Malyshev'" References: <54AAF98B.4020709@gmail.com> <001b01d029bb$fa687fc0$ef397f40$@tekwire.net> <00a201d02ac7$406a4830$c13ed890$@tekwire.net> In-Reply-To: Date: Thu, 8 Jan 2015 17:22:35 +0100 Message-ID: <004801d02b5f$507421e0$f15c65a0$@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+kkOgWpn3PeY833kwGP3HvhATjV2lMChcgIAwHV7IBCAiSTtMcB5W5x9wGAwYgSA4J72AkBy3vV4gKwaDGimq3sBOA= Content-Language: fr X-Antivirus: avast! (VPS 150108-0, 08/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?=) 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=C3=A7ois