Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81431
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.173 as permitted sender)
Sender: Michael Wallner <mike.php.net@gmail.com>
Message-ID: <54CB93A3.8090108@php.net>
Date: Fri, 30 Jan 2015 15:22:27 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Ferenc Kovacs <tyra3l@gmail.com>
CC: PHP Internals <internals@lists.php.net>
References: <DDA98D4F-2105-415A-B921-01A622091FA9@php.net>	<FA3623B5-6D82-475C-9E44-02287137E912@php.net>	<54CB8AED.8040803@php.net> <CAH-PCH76w96PSEs5GWVS-LZoMcK809dC92jm=v0+F9gyCFVuZQ@mail.gmail.com>
In-Reply-To: <CAH-PCH76w96PSEs5GWVS-LZoMcK809dC92jm=v0+F9gyCFVuZQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http
From: mike@php.net (Michael Wallner)

On 30/01/15 15:08, Ferenc Kovacs wrote:
> 
> 
> On Fri, Jan 30, 2015 at 2:45 PM, Michael Wallner <mike@php.net
> <mailto:mike@php.net>> wrote:
> 
>>     https://wiki.php.net/rfc/pecl_http

> hi,
> 
> just a small question: what will be the upgrade path for existing
> pecl_http users upgrading to 7.0?

I'd consider PHP7's http extension a new major version, i.e. v3.

> if we would just move the current ext as is into php-src it would be no
> problem for them, but based on the recent discussion that is unlikely
> and if we change the userland api they will be forced to upgrade their
> code (except if we are willing to provide a php7 compatible version of
> pecl_http on pecl.php.net <http://pecl.php.net>, but I think that would
> be a PITA for everybody).

I definitley would stay away from having a separate PHP7 compatible PECL
version, but coming v2 releases could take measures to prepare any
transition to the PHP7 API.

> ofc. this isn't a blocker problem, but something we should keep in mind.

Alas, not much has changed so far:

 - no automatic json_decode() into $_POST:

	I doubt anybody used that


 - default etag hash algo for dynamic response bodies has changed to
   sha1 from crc32 and cannot be changed through an INI setting

	etags on dynamic content are, well, subject to change anyway,
	so I don't see major troubles


 - missing http\QueryString::xlate()

	This is a real BC break, though.


-- 
Regards,
Mike