Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:102430 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 13726 invoked from network); 25 Jun 2018 16:33:03 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Jun 2018 16:33:03 -0000 Authentication-Results: pb1.pair.com smtp.mail=johannes@schlueters.de; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=johannes@schlueters.de; sender-id=unknown Received-SPF: error (pb1.pair.com: domain schlueters.de from 84.19.169.162 cause and error) X-PHP-List-Original-Sender: johannes@schlueters.de X-Host-Fingerprint: 84.19.169.162 mail.experimentalworks.net Received: from [84.19.169.162] ([84.19.169.162:35910] helo=mail.experimentalworks.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A8/E9-50433-D39113B5 for ; Mon, 25 Jun 2018 12:33:03 -0400 Received: from kuechenschabe.fritz.box (ppp-188-174-118-230.dynamic.mnet-online.de [188.174.118.230]) by mail.experimentalworks.net (Postfix) with ESMTPSA id 63D5D40DF9; Mon, 25 Jun 2018 18:32:58 +0200 (CEST) Message-ID: <1529944377.4441.14.camel@schlueters.de> To: Ralph Schindler , internals@lists.php.net Date: Mon, 25 Jun 2018 18:32:57 +0200 In-Reply-To: <810529e6-f873-fbe5-c182-4de827fe46a0@ralphschindler.com> References: <1529936020.4441.10.camel@schlueters.de> <810529e6-f873-fbe5-c182-4de827fe46a0@ralphschindler.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] PHP 2^3 From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=) On Mo, 2018-06-25 at 09:58 -0500, Ralph Schindler wrote: > On 6/25/18 9:13 AM, Johannes Schlüter wrote: > > > > On Mo, 2018-06-25 at 12:30 +0000, Zeev Suraski wrote: > > > > > > 3. Foreign Function Interface support. > > Related to this on a non-PHP-code and strategic matter I would like > > to rethink PECL. Currently maintenance and installing extensions > > using it is a pita. This should be doable in a nicer way. > Is it worthwhile to also consider some form of safe runtime > registration  of extensions (or extension-like whatever that looks > like in a JIT model).. A la dl()? > > I realize in today's age of containerized projects (1 php install per > project, everything owned by root per-se) makes PHP with esoteric  > extensions much easier, it still would be nice if I could composer  > install a specific version of an extension; like xdebug in a  > require-dev, or require one of the new kafka extensions at the > project level. > For a goal I agree, I however see hurdles on the way (need to avoid startup costs on each request, eventually need to handle use of different versions of the extension on subsequent requests) I believe a more narrow and stable extension API might be a start for that. johannes