Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:80259 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84579 invoked from network); 7 Jan 2015 22:14:12 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Jan 2015 22:14:12 -0000 Authentication-Results: pb1.pair.com smtp.mail=francois@tekwire.net; spf=softfail; sender-id=softfail Authentication-Results: pb1.pair.com header.from=francois@tekwire.net; 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:28505] helo=smtp2-g21.free.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F6/F0-12859-3BFADA45 for ; Wed, 07 Jan 2015 17:14:12 -0500 Received: from moorea (unknown [82.240.16.115]) by smtp2-g21.free.fr (Postfix) with ESMTP id 64A254B0293; Wed, 7 Jan 2015 23:12:12 +0100 (CET) Reply-To: To: "'Pierre Joye'" , "'Derick Rethans'" Cc: "'PHP internals'" , "'Sara Golemon'" , "'Stanislav Malyshev'" , "'Benjamin Eberlei'" References:

<54AAF98B.4020709@gmail.com> <001b01d029bb$fa687fc0$ef397f40$@tekwire.net> In-Reply-To: Date: Wed, 7 Jan 2015 23:14:05 +0100 Message-ID: <00a201d02ac7$406a4830$c13ed890$@tekwire.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: fr Thread-Index: AQKBrOMj1TuM8+kkOgWpn3PeY833kwGP3HvhATjV2lMChcgIAwHV7IBCAiSTtMcB5W5x9wGAwYgSmuylDpA= X-Antivirus: avast! (VPS 150107-1, 07/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] > > ... here, > it is proposed to bundle scripts that will be executed at runtime like = any > other script, except that nothing can be done with them, not even = disable > them if not required (like using its own glue codes). I agree. Bundling scripts in extensions to execute them at each RINIT = is, IMO, not a good idea (mostly for performance reasons and lack of = control, as you note), but I keep thinking that a mechanism to embed PHP = scripts in extensions and make them available via a common stream = wrapper can be useful. What I don't like is the fact to execute them = automatically at every RINIT. I prefer to let the extension free to load = its PHP code when its logic decides it is needed. > Pickle integration is almost finished, that solves your worries about = composer and pecl extensions. Both mechanisms can coexist. They are not incompatible and probably = fulfill different needs. You are asking for a standard path for plain files linked to an = extension. As putting the shared library and plain files together is not = a good idea, what about something like this : /lib/php/extensions/php/ A C macro can be defined to provide the path to the extension C code, in = order to avoid hardcoding it (this way, it could be modified in the = future). At install time, we could say that every files under = /php/install, if this dir exists, are installed = there. It is just an example but does it correspond to the mechanism you were = thinking about ? What is not clear to me is the question of = packaging/versioning/deployment. If you consider the PHP glue code is = modified more often than the C code, which will be the most frequent = case, how do you version/distribute partial packages ? or do you deliver = 2 packages with independent versioning and dependencies together ? In = this case, should we define a versioning convention for both packages ? Regards Fran=C3=A7ois