Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:80247 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 35025 invoked from network); 7 Jan 2015 10:02:28 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Jan 2015 10:02:28 -0000 Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender) X-PHP-List-Original-Sender: derick@php.net X-Host-Fingerprint: 82.113.146.227 xdebug.org Linux 2.6 Received: from [82.113.146.227] ([82.113.146.227:60044] helo=xdebug.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4E/A1-17382-2340DA45 for ; Wed, 07 Jan 2015 05:02:27 -0500 Received: from localhost (localhost [IPv6:::1]) by xdebug.org (Postfix) with ESMTPS id 63F64E202D; Wed, 7 Jan 2015 10:02:22 +0000 (GMT) Date: Wed, 7 Jan 2015 10:02:22 +0000 (GMT) X-X-Sender: derick@whisky.home.derickrethans.nl To: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= cc: 'Pierre Joye' , 'Stanislav Malyshev' , 'Sara Golemon' , 'Benjamin Eberlei' , 'PHP Internals' In-Reply-To: <001b01d029bb$fa687fc0$ef397f40$@tekwire.net> Message-ID: References: <54AAF98B.4020709@gmail.com> <001b01d029bb$fa687fc0$ef397f40$@tekwire.net> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1132757819-1420624942=:4080" Subject: RE: [PHP-DEV] [RFC] Extension Prepend Files From: derick@php.net (Derick Rethans) --8323329-1132757819-1420624942=:4080 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 6 Jan 2015, Fran=C3=A7ois Laupretre wrote: > > De : Pierre Joye [mailto:pierre.php@gmail.com] >=20 > > 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). >=20 > I am sorry to say that but, with all due respect, I have a totally opposi= te opinion. >=20 > IMHO, this PHP code (and any other data we want to embed) is an=20 > integral part of the extension. A compiled extension is a consistent=20 > piece of code, it is contained in a single file and should not be=20 > split to separate files. That's very much the case. One extension, one "install". It doesn't=20 matter whether some of the extension is written in C, and other parts in=20 PHP. HHVM is *all* about this. Making use of C where you need it, and=20 otherwise just write the simpler *but integral* border functionality in=20 PHP for faster maintenance and development. > The first reason is that, if we consider a released extension as a=20 > conceptual unit, the best way to protect its integrity is to store it=20 > as a single file. Storing it as separate files brings a lot of=20 > potential issues : files can be renamed, deleted, etc. Offline tools=20 > like composer can take care of integrity but, from a final user pov,=20 > it will never be as clear as a single file (.so for extensions, or=20 > package for PHP software). +1 > The second reason, more important, is about inter-communication=20 > between C and PHP. I understand the pov : it is easier to allow=20 > distros to upgrade an extension's PHP code without upgrading the C=20 > code. But, if we consider the PHP code as an integral part of the=20 > extension, this should be avoided, as C and PHP code need to be kept=20 > in sync. +1 > If you allow upgrading the PHP code only, you must consider them as=20 > two separate pieces of code and, so, consider BC in the way they=20 > communicate together. This is a perfectly valid scheme, but, in this=20 > case, this PHP code is not part of your extension anymore, it is a=20 > separate software with its own version/release numbering, which=20 > communicates with your extension. If distros could cherry-pick the C=20 > files they want to upgrade, depending on the features they want to=20 > provide, would you be ready to keep BC between all your C files ? The=20 > same if libc was distributed as a bunch of individually-upgradable=20 > files, each defining a function, with consistency ensured by metadata=20 > and an offline tool. >=20 > So, to summarize my opinion : if an extension writer wants to=20 > distribute part of his code in PHP and if he wants this code to be=20 > upgradeable in an independent way, he must distribute them as an=20 > independent software package, not as part of the extension. The whole=20 > code to consider as part of an extension, whatever the language, must=20 > be kept in sync. And the best way to achieve this is to store it in a=20 > single file. +1 =E2=80=94 and the latter is what Benjamin was suggesting, albeit perhaps= in=20 not the most technologically sound way. cheers, Derick --=20 http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine --8323329-1132757819-1420624942=:4080--