Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:81374 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 59089 invoked from network); 29 Jan 2015 12:01:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Jan 2015 12:01:52 -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:36678] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 66/29-09212-E212AC45 for ; Thu, 29 Jan 2015 07:01:51 -0500 Received: (qmail 9264 invoked by uid 89); 29 Jan 2015 12:01:46 -0000 Received: by simscan 1.3.1 ppid: 9256, pid: 9261, t: 0.0677s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.189.147.37) by mail4.serversure.net with ESMTPA; 29 Jan 2015 12:01:46 -0000 Message-ID: <54CA212A.20007@lsces.co.uk> Date: Thu, 29 Jan 2015 12:01:46 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http From: lester@lsces.co.uk (Lester Caine) On 29/01/15 11:40, Andrea Faulds wrote: > * Why do we need pecl/http? > * Why should pecl/http be merged into PHP core? > * Why should pecl/http be enabled by default? > * Why should we have our own HTTP API and not follow PSR-7? > * What does it offer over PHP’s existing HTTP capabilities? > * Why should we merge this rather than, say, filling in gaps in PHP’s HTTP capabilities? On one hand third party packages are being pushed in place of the existing built in functions. Here a new set of built in functions are being proposed. Having used Apache for many years and now moved to Nginx as my 'interface', just where does this fit into the overall jigsaw. Using Nginx to handle the static stuff and only passing dynamic calls to php_fpm, just what http functionality is needed? The main reason for asking this question actually relates to implementing a server for tzdist which I can easily handle with the Nginx/php_fpm framework, and that should serve static pages until a change of version requires building a new data set. Is this the sort of process that can be handled totally within PHP and does that actually make sense where a large volume of static data is cached? -- 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