Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:80234 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 63385 invoked from network); 6 Jan 2015 14:21:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Jan 2015 14:21:01 -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:34017] helo=smtp2-g21.free.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B2/10-61664-B4FEBA45 for ; Tue, 06 Jan 2015 09:21:00 -0500 Received: from moorea (unknown [82.240.16.115]) by smtp2-g21.free.fr (Postfix) with ESMTP id E0BEE4B0150; Tue, 6 Jan 2015 15:19:02 +0100 (CET) Reply-To: To: "'Pierre Joye'" , "'Derick Rethans'" Cc: "'Stanislav Malyshev'" , "'Sara Golemon'" , "'Benjamin Eberlei'" , "'PHP Internals'" References: <54AAF98B.4020709@gmail.com> In-Reply-To: Date: Tue, 6 Jan 2015 15:20:51 +0100 Message-ID: <001b01d029bb$fa687fc0$ef397f40$@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+kkOgWpn3PeY833kwGP3HvhATjV2lMChcgIAwHV7IBCmxbksUA= X-Antivirus: avast! (VPS 150106-0, 06/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] > 2. We have no easy way to actually release and deploy adhoc scripts, > used by a given extension >=20 > For 2., it is one of the thing I can imagine implementing in pickle. > Or even better add it a s part of the build scripts and macros. Either > will work, even for binary install on windows f.e.. I would really > like to define a clear location relative to the extension directory. > This location will be used by this new feature, if implemented. I also > think that it should be either part of the current prepend setting, by > default and system only, or another setting. What I really consider as > a bad practice is any kind of bundling scripts in the extensions, that > will be a real pain to maintain and it opens some unknown can of > worms. Distros may also prefer to have that script outside the > extension, easier for cherry picks update when necessary (f.e. > security fixes). I am sorry to say that but, with all due respect, I have a totally = opposite opinion. IMHO, this PHP code (and any other data we want to embed) is an integral = part of the extension. A compiled extension is a consistent piece of = code, it is contained in a single file and should not be split to = separate files. The first reason is that, if we consider a released extension as a = conceptual unit, the best way to protect its integrity is to store it as = a single file. Storing it as separate files brings a lot of potential = issues : files can be renamed, deleted, etc. Offline tools like composer = can take care of integrity but, from a final user pov, it will never be = as clear as a single file (.so for extensions, or package for PHP = software). The second reason, more important, is about inter-communication between = C and PHP. I understand the pov : it is easier to allow distros to = upgrade an extension's PHP code without upgrading the C code. But, if we = consider the PHP code as an integral part of the extension, this should = be avoided, as C and PHP code need to be kept in sync. If you allow upgrading the PHP code only, you must consider them as two = separate pieces of code and, so, consider BC in the way they communicate = together. This is a perfectly valid scheme, but, in this case, this PHP = code is not part of your extension anymore, it is a separate software = with its own version/release numbering, which communicates with your = extension. If distros could cherry-pick the C files they want to = upgrade, depending on the features they want to provide, would you be = ready to keep BC between all your C files ? The same if libc was = distributed as a bunch of individually-upgradable files, each defining a = function, with consistency ensured by metadata and an offline tool. So, to summarize my opinion : if an extension writer wants to distribute = part of his code in PHP and if he wants this code to be upgradeable in = an independent way, he must distribute them as an independent software = package, not as part of the extension. The whole code to consider as = part of an extension, whatever the language, must be kept in sync. And = the best way to achieve this is to store it in a single file. Regards, Fran=C3=A7ois