Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:93163 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 5224 invoked from network); 10 May 2016 19:01:23 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 May 2016 19:01:23 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:57998] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7F/27-63163-00032375 for ; Tue, 10 May 2016 15:01:21 -0400 Received: (qmail 23517 invoked by uid 89); 10 May 2016 19:01:17 -0000 Received: by simscan 1.3.1 ppid: 23511, pid: 23514, t: 0.0721s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 10 May 2016 19:01:17 -0000 To: internals@lists.php.net References: <59e5902d-004f-33b5-5d6f-991d89371e05@php.net> <2461b452-f595-6fa9-4e33-9e163f79d162@fleshgrinder.com> Message-ID: <57322FFC.1040109@lsces.co.uk> Date: Tue, 10 May 2016 20:01:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <2461b452-f595-6fa9-4e33-9e163f79d162@fleshgrinder.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Allow loading extensions by name From: lester@lsces.co.uk (Lester Caine) On 10/05/16 17:27, Fleshgrinder wrote: >> Please read and comment : >> > >> > https://wiki.php.net/rfc/load-ext-by-name >> > > +1 and I am wondering why nobody else ever came to this idea. The idea has been proposed before, but the addition of php_ for windows installs has not been universally applied. Extensions like eAccelerator, adodb and other third party extensions that did not form part of the windows 'installation' files. Most of these have been killed off by the restructuring of the core so it's probably less of a problem now than 5 years ago! Another negative is the fact that most Linux installations do not use entries in the php.ini file to enable extensions, preferring to manage them via the package manager. THAT particular practice is something I already copy back to the windows installs, using individual .ini files for each extension, and stripping those extensions and settings from the main php.ini. This is not simply a matter of adding another load mechanism to the mix, so any rfc should perhaps bear in mind all the aspects of 'package management' process? Certainly it's not quite as simple as assuming windows extensions start php_ and end .dll ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk