Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

> Caching connections within the same request and reusing them is not > spooky, but caching them long term, across requests, across security > domains, for extended time - is spooky. This is exactly what reverse proxies like Nginx and the Akamai CDN do: reuse the connection between the proxy and o

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On 04/02/15 18:57, Pavel Kouřil wrote: > On Wed, Feb 4, 2015 at 6:17 PM, Andrea Faulds wrote: >> Hey, >> >>> On 4 Feb 2015, at 17:10, Crypto Compress >>> wrote: >>> I would go with Http\ >>> >>> Why not the reserved Php\Http\? >> >> This sounds good to me. php\ is already reserved, and i

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On 08/02/15 23:25, Stanislav Malyshev wrote: >> Youself said that HTTP is a stateless protocol, so how would a >> connection in an "unclean state" look like in your opinion? > > Connection and protocol are different things. In connection, you could > be in the middle of the protocol - i.e. sendin

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On 08/02/15 23:25, Stanislav Malyshev wrote: > Hi! > >> Are you saying performance is not the reason we use persistent handles? > > It is, for databases where connection setup is expensive. Even then > persistent handles are not always the best solution. But with DB, you > routinely connect to on

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi! > Are you saying performance is not the reason we use persistent handles? It is, for databases where connection setup is expensive. Even then persistent handles are not always the best solution. But with DB, you routinely connect to one service, with one set of credentials, and need this conn

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi Stas! On 05/02/15 21:46, Stanislav Malyshev wrote: > Hi! > >> Uhm, I'm not sure I understand :-? Weren't I supposed to measure exacly >> that? Let me know, if you wanted something else to be compared. > > I wanted to know why we need persistent resources. You brought comparing > persistent re

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi! > Uhm, I'm not sure I understand :-? Weren't I supposed to measure exacly > that? Let me know, if you wanted something else to be compared. I wanted to know why we need persistent resources. You brought comparing persistent resources to reopening connection each time as an argument that we ne

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi Stas! On 05/02/15 21:28, Stanislav Malyshev wrote: > Hi! > >> Does the following kcachegrind screenshot give an idea (I used a minimum >> node cost of 10% to simplify the graph)? >> >> Left is raphf enabled (24M Ir) and on the right raphf disabled (35M Ir): >> http://dev.iworks.at/ext-http/rap

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi! > Does the following kcachegrind screenshot give an idea (I used a minimum > node cost of 10% to simplify the graph)? > > Left is raphf enabled (24M Ir) and on the right raphf disabled (35M Ir): > http://dev.iworks.at/ext-http/raphf.png > > Have a look on the top-most far-right highlighted b

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi Pierre! On 05/02/15 18:49, Pierre Joye wrote: > > On Feb 5, 2015 3:17 PM, "Michael Wallner" > wrote: >> >> Compare the timings accessing google 20 times sequentually: >> >> With default of raphf.persistent_handle.limit=-1 (unlimited): >> █ mike@smugmug:~$ time php -r 'for

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On Feb 5, 2015 3:17 PM, "Michael Wallner" wrote: > > Hi Stas! > > On 05/02/15 00:43, Stanislav Malyshev wrote: > > Hi! > > > >> Points explicitely marked for discussion in the RFC itself: > >> > >> * pecl/propro > >> Proxies for properties representing state in internal C structs > >> https://

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On 05/02/15 10:03, Stanislav Malyshev wrote: > Hi! > >> Yes, I mean $_POST (and $_FILES). It's been requested multiple times, >> but I know it's quite controversial. I think this approach is better >> than any other proposed yet (think $_PUT and stuff). > > You're building an OO next-generation A

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On 05/02/15 09:53, Stanislav Malyshev wrote: > Hi! > >> Databases (see my pecl/pq example in the RFC), key/value stores, message >> queues, whatever you can think of. > > HTTP and databases are principally different. HTTP protocol is stateless > message-oriented protocol, and database connection

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi! > Yes, I mean $_POST (and $_FILES). It's been requested multiple times, > but I know it's quite controversial. I think this approach is better > than any other proposed yet (think $_PUT and stuff). You're building an OO next-generation API, why you still need $_PUT or $_FILES or anything like

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi Stas! On 05/02/15 09:30, Stanislav Malyshev wrote: >> The sole code change would be removing the check for POST, i.e. >> `!strcasecmp(SG(request_method),"POST")` so that actually any request >> method with a recognized content-type (i.e. application/form-data or >> application/x-www-form-urlen

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi! > Databases (see my pecl/pq example in the RFC), key/value stores, message > queues, whatever you can think of. HTTP and databases are principally different. HTTP protocol is stateless message-oriented protocol, and database connection protocols have very little in common with HTTP. > To dem

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi Stas! On 05/02/15 09:30, Stanislav Malyshev wrote: > Hi! > >> think raphf is far more of practical use. Why should HTTP, or even more >> HTTPS or HTTP2, be any different than another service, especially when > > Which "another service"? Databases (see my pecl/pq example in the RFC), key/valu

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi! > think raphf is far more of practical use. Why should HTTP, or even more > HTTPS or HTTP2, be any different than another service, especially when Which "another service"? > HTTP APIs are so common nowadays. HTTP APIs are common, but almost none of them ever require persistent connections.

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi Stas! On 05/02/15 00:43, Stanislav Malyshev wrote: > Hi! > >> Points explicitely marked for discussion in the RFC itself: >> >> * pecl/propro >> Proxies for properties representing state in internal C structs >> https://wiki.php.net/rfc/pecl_http#peclpropro >> >> * pecl/raphf >> (Persist

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi all, On Thu, Feb 5, 2015 at 2:10 AM, Crypto Compress < cryptocompr...@googlemail.com> wrote: > Why not the reserved Php\Http\? +1 We must have the rule in CONDING_STANDARDS. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi! > Points explicitely marked for discussion in the RFC itself: > > * pecl/propro > Proxies for properties representing state in internal C structs > https://wiki.php.net/rfc/pecl_http#peclpropro > > * pecl/raphf > (Persistent) handle management within objects instead of resources > ht

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On Wed, Feb 4, 2015 at 6:17 PM, Andrea Faulds wrote: > Hey, > >> On 4 Feb 2015, at 17:10, Crypto Compress >> wrote: >> >>> I would go with Http\ >> >> Why not the reserved Php\Http\? > > This sounds good to me. php\ is already reserved, and it’s similar to the > common community convention of v

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi, On Wed, Feb 4, 2015 at 7:26 PM, Andrea Faulds wrote: > Hey, > >> On 4 Feb 2015, at 17:23, Andrey Andreev wrote: >> >> I'm not sure about namespacing it in the first place, but otherwise I >> agree with you - acronyms should be capitalised. > > What’s your objection? We either namespace it, o

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hey, > On 4 Feb 2015, at 17:23, Andrey Andreev wrote: > > I'm not sure about namespacing it in the first place, but otherwise I > agree with you - acronyms should be capitalised. What’s your objection? We either namespace it, or we have to add some weird prefix to avoid conflicts. I’d rather w

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi, On Wed, Feb 4, 2015 at 7:17 PM, Andrea Faulds wrote: > Hey, > >> On 4 Feb 2015, at 17:10, Crypto Compress >> wrote: >> >>> I would go with Http\ >> >> Why not the reserved Php\Http\? > > This sounds good to me. php\ is already reserved, and it’s similar to the > common community convention

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hey, > On 4 Feb 2015, at 17:10, Crypto Compress > wrote: > >> I would go with Http\ > > Why not the reserved Php\Http\? This sounds good to me. php\ is already reserved, and it’s similar to the common community convention of vendor\packagename. (e.g. ajf\escapes.) Would work well with Compo

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

I would go with Http\ Why not the reserved Php\Http\? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On Feb 4, 2015 8:17 PM, "Michael Wallner" wrote: > > On 04/02/15 14:06, Pavel Kouřil wrote: > > > Hello, > > > > as I mentioned already in the other thread - there are currently no > > coding standards related to namespace naming in > > https://github.com/php/php-src/blob/master/CODING_STANDARDS a

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On 04/02/15 14:06, Pavel Kouřil wrote: > Hello, > > as I mentioned already in the other thread - there are currently no > coding standards related to namespace naming in > https://github.com/php/php-src/blob/master/CODING_STANDARDS and the > coding standards should probably be updated before voti

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On Wed, Feb 4, 2015 at 2:00 PM, Michael Wallner wrote: > Hi! > > Do we want to discuss anything further before I put this to vote again? > > https://wiki.php.net/rfc/pecl_http > > Points explicitely marked for discussion in the RFC itself: > > * pecl/propro > Proxies for properties representing

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On 30/01/15 17:45, Lester Caine wrote: > On 30/01/15 14:22, Michael Wallner wrote: >> - 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, >>

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On 30/01/15 14:22, Michael Wallner wrote: > - 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 I presum

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On 30/01/15 15:08, Ferenc Kovacs wrote: > > > On Fri, Jan 30, 2015 at 2:45 PM, Michael Wallner > 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 conside

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On Fri, Jan 30, 2015 at 2:45 PM, Michael Wallner wrote: > On 29/01/15 21:25, Michael Wallner wrote: > > > >> On 29 01 2015, at 12:14, Michael Wallner >> > wrote: > >> > >> Hi! > >> > >> I’ve rewritten the RFC for pecl_http and hopefully addressed most of > >> the things ment