Re: [PSR-17] Define where the file position indicator (cursor) ends up to ensure Stream compatibility

[Tobias Nyholm]

PSR-7 nor PSR-17 specify where the cursor should be positioned and I don't 
think it should either. 

Sure, one would think it makes sense to have the pointer at the beginning 
of the stream because "that is why I will start reading". But that does not 
take middleware into consideration. A middleware that write stuff to the 
end of the stream would never like the cursor to be at the beginning...

Other edge cases to consider are non-seekable streams or just 
non-rewindable?

I think we should not try to amend a PSR and specify a "default behavior" 
because: 
- Since specifying a "default behavior" for this is close to impossible 
(just see Woody's and Rasmus' short discussion) 
- Neither currently PSR mention it
- Thanks to Martijn research we can see that the implementations are rather 
spitted as well

The consumer of a stream must always make sure to move the cursor before 
the are using a stream. (Or use __toString())



Den måndag 7 januari 2019 kl. 16:56:03 UTC+1 skrev Rasmus Schultz:
>
> > This does not sound like something that can just be errata’d in, and 
> defining behaviour now will lead to breaking changes in implementations
>
> I have to disagree with this assertion.
>
> There's no breaking change versus a previous, incorrect specification - 
> the problem here is a simple omission, not an error in the specification.
>
> The interface won't change, so this isn't a breaking change to the package 
> either, and should be versioned either as a bugfix (1.0.1) or a feature 
> (1.1.0).
>
> Yes, this will render some existing implementations incompatible with the 
> specification - that's okay, these packages will need bugfix releases, and 
> will then be compatible with both versions of the PSR package.
>
> No, you won't be able to look at the package and tell from it's 
> requirements whether it's been updated with regards to the corrected 
> specification - but that's probably okay too, as this will be a quick and 
> easy fix for most packages. (Packages that don't satisfy the updated 
> specification simply had bugs, we just didn't know before, and that's 
> normal - that's what bugfix releases are for.)
>
> I understand you strictly could make an argument that this is a breaking 
> change - but it's much easier and simpler for everyone to just treat this 
> as a bugfix.
>
> The only alternative is an entirely new PSR, which is much harder and 
> messier for all vendors and consumers involved and just sounds like a 
> meaningless waste of time.
>
> Some of the existing implementations will be rendered "buggy", but bugfix 
> releases will need to be published either way, and a bugfix is a much 
> smoother transition for everyone. Again, there's no breaking change versus 
> a previous specification - it's an omission, not an error.
>
> Lastly, it would surely be better if everyone gets these fixes 
> automatically with a composer update - as opposed to forcing everyone to do 
> the whole dependency song-and-dance just to get what is essentially a 
> simple bugfix.
>
> Let's correct this mistake and move on, please.
>
> On Saturday, December 29, 2018 at 1:07:31 AM UTC+1, Martijn van der Ven 
> wrote:
>>
>> There seems to be some disagreement on where the file position indicator 
>> (cursor) ends up upon the creation of a Stream instance. I have done some 
>> minor testing and put the results on GitHub 
>> . This can lead to 
>> incompatibilities when doing something like:
>>
>> echo (new StreamFactory)->createStream('Hello!')->read(6);
>>
>>
>>- createStream() seems to be the most contested. The cursor goes at 
>>the start or end of the string. Even more surprising (to me) is that 
>>Diactoros will result in a different state depending on whether you use 
>> its 
>>own factory or the tuupola one. (Again showing how compatibility may be 
>> an 
>>issue here!)
>>- createStreamFromResource() seems to be agreed upon by all 
>>implementations: keep the cursor wherever it was at in the original 
>>resource. Even without specifically being defined by the PSR this makes a 
>>lot of sense to me, and I will propose adding a test for this to the 
>>(official) unit tests.
>>- createStreamFromFile() has one of the tested implementations do its 
>>own thing: berlioz/http-message copies the contents of the file into a 
>> new 
>>stream and puts the cursor at the end. Every other implementations puts 
>> the 
>>cursor at the start, matching where it would be if fopen() is called on a 
>>file.
>>
>> Of course the (official) unit tests 
>>  that go with the 
>> PSR-17 interfaces do not have tests for any of this as it isn’t covered by 
>> the PSR itself.
>>
>> The default for createStream() is a coin toss to me. I see no clear 
>> argument for either position. But I do think the PSR should define a 
>> location. This does not sound like something that 

Re: [DISCUSSION] PSR-18 HTTP Client Acceptance Vote

[Tobias Nyholm]

Hey. 

As mentioned, HTTPlug has prepared a 2.0 to make sure it is supporting the 
new PSR. They are just waiting for the PSR to be released. 
https://github.com/php-http/httplug/tree/2.x

As of clients, Buzz has been adapting to every version of the PSR and has 
their 0.17.3 release with the latest version of psr/http-client. 
https://github.com/kriswallsmith/Buzz

How many is needed? Also, should these really be in the meta doc?

Den söndag 14 oktober 2018 kl. 15:35:26 UTC skrev Michael Cullum:
>
> Hi,
>
> One of the core requirements for a specification to proceed from review 
> and be fully accepted is the demonstration of multiple full 
> implementations. No such implementations are mentioned in the metadoc or 
> vote.
>
> Could references to some implementations please be provided (and they 
> should also be added to the metadoc)?
>
> Thanks,
> Michael
>

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/267c9786-2595-46cd-bd32-d37ade46b951%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [WG][VOTE] PSR-17 Review

[Tobias Nyholm]

I really like the work you've put in and I'm sorry I'm late replying here. 
As you may or may not know, I'm maintaining Buzz, HTTPlug (and sometimes 
Guzzle). I've also written a PSR7 implementation with factories from 
HTTPlug and php-interop. (https://github.com/nyholm/psr7)

I've just read and tested(!!) the specification we are voting on. I'm not 
sure it works to be honest. Here are a few things I found: 

*Namespace* (minor): Should we really share the namespace with PSR7? Just 
use 'Psr\Http\MessageFactory'

*Interfaces extending* (critical): I've read the arguments on the meta 
document. The four bullets 
(https://github.com/php-fig/fig-standards/blob/master/proposed/http-factory/http-factory-meta.md#53-why-do-some-interfaces-extend-others)
 
are all very true but none is an argument for the interface to extend each 
other. 

The first bullet about this in the meta document says: 
> The RequestFactoryInterface and ServerRequestFactoryInterface may each 
need to build a UriInterface from a string URI.

Inheritance is not the answer here. Please use a constructor to inject the 
dependencies (or if you are lazy, do like me 
https://github.com/Nyholm/psr7/blob/0.3.0/src/Request.php#L58). 
Consider a MailFactoryInterface. The mail factory implementation may need 
an EmailValidator. Should the MailFactoryInterface really extend 
EmailValidatorInterface?...

I found it very hard to write factory implementation with these interfaces. 
Most of my classes have to extend each other and I have to put the stream 
factory implementation in a Trait. 

*Existing libraries* (major): HTTPlug has been an "de-facto" standard for 
almost 3 years now. The php-http/message-factory has been downloaded over 
4M times. We (HTTPlug) like PSR-17 and we think it is about time PHP-Fig 
delivers a "real" standard for this. However, the current state of PSR-17 
will not allow HTTPlug to extend PSR-17. It will also not allow 
implementing libraries (like guzzle/psr7 and nyholm/psr7) to have one 
RequestFactory for both PSR-17 and HTTPlug. 

There is no mentioning about HTTPlug in the meta docs so I'm not sure it 
has been discussed. This is important for the adoption of the PSR-17. 


-

These are 3 of my concerns. I really hope that everybody in the working 
group have considered these 3 things before you voted. Or else there I 
believe there is a change to change your vote until the voting period is 
over or until everybody has voted. 
 
I will give my vote on the 29th of May. 



Den torsdag 17 maj 2018 kl. 16:52:17 UTC+2 skrev Glenn Eggleton:
>
> +1
>
> On Tuesday, May 15, 2018 at 12:06:02 PM UTC-4, Matthew Weier O'Phinney 
> wrote:
>>
>> Woody has delegated to me to open a vote to enter the REVIEW period for 
>> PSR-17. This vote is open only to PSR-17 Working Group members; at this 
>> time, that means: 
>>
>> - Woody Gilk (Editor) 
>> - myself (Sponsor) 
>> - Stefano Torresi 
>> - Matthieu Napoli 
>> - Korvin Szanto 
>> - Glenn Eggleton 
>> - Oscar Otero 
>> - Tobias Nyholm 
>>
>> The by-laws do not stipulate a time-frame for how long the vote must 
>> run, though 2 weeks is the standard period. As such, the vote will run 
>> until 23:59:59 on 29 May 2018, or until all members have responded. Once 
>> the vote is closed, I 
>> will post the results, and indicate next steps for the proposal. 
>>
>> PLEASE DO NOT RESPOND TO THIS POST UNLESS YOU ARE ONE OF THE MEMBERS 
>> LISTED ABOVE. 
>>
>> -- 
>> Matthew Weier O'Phinney 
>> mweiero...@gmail.com 
>> https://mwop.net/ 
>>
>

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/779dc60c-8b87-4245-8152-fc566e27b932%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The progress of HTTP client

[Tobias Nyholm]

Thank you Luis for the feedback. Here are some short answers: 

* Regarding async: See the meta document: 
https://github.com/php-fig/fig-standards/blob/master/proposed/http-client/http-client-meta.md
* Method signature: We want to make sure that major libraries could 
implement this interface without breaking BC. 
* Regarding exceptions' verbosity: See the meta document
* Exceptions is thrown when there is no response. =)

See the meta document and the current specification. Most of your ideas has 
been visited already.

https://github.com/php-fig/fig-standards/blob/master/proposed/http-client/http-client.md


Den fredag 16 mars 2018 kl. 17:24:07 UTC+1 skrev Luis Pabón:
>
> My 2p: 
>
>
>- This PSR needs async, otherwise there's not much value on it - I'd 
>recommend following closely what guzzle is already doing
>- sendRequest is redundant. public function send(RequestInterface 
>$request): Response
>- Exceptions should be way more verbose: need BadRequestException, 
>ConflictException, TimeoutException, UnauthorisedException etc to 
>accurately error-handle without boilerplate (eg checking status code).
>- Exceptions must also give access to the response as well as the HTTP 
>status code separately
>
>
> On Sunday, February 25, 2018 at 7:00:40 PM UTC, Barry vd. Heuvel wrote:
>>
>> Good to hear it was just a typo :)
>>
>> > The specification looks good, we are currently deciding on an upgrade 
>> path from HTTPlug. We have a proposal that we think will work. 
>>
>> Does that mean the interface is likely to remain the same?
>>
>> I'm currently working on an upgrade for Omnipay from Guzzle to 
>> (hopefully) PSR-18 (current work in progress is also based on HTTplug), 
>> hence this PSR :)
>>
>> Op maandag 19 februari 2018 22:51:50 UTC+1 schreef Alessandro Lai:
>>>
>>> As per our bylaws (see 
>>> https://www.php-fig.org/bylaws/psr-workflow/#abandoned), abandonment 
>>> must be explicitly declared either by an abandonment vote, or by a 
>>> secretary, but with some prerequisites:
>>>
>>>  - missing editor or sponsor for more than 60 days (not the case here)
>>>  - no activity in 6 months (not the case either, see commits on draft: 
>>> https://github.com/php-fig/fig-standards/commits/master/proposed/http-client
>>> )
>>>
>>> So yes, PSR-18 is not abandoned but in draft stage, as correctly stated 
>>> in our repo/site: https://www.php-fig.org/psr/#draft
>>>
>>> Il giorno domenica 18 febbraio 2018 12:28:18 UTC+1, Stefano Torresi ha 
>>> scritto:
>>>>
>>>> As far as I know, PSR-18 has never been marked as abandoned, I don't 
>>>> even think the requirements to do so have ever been satisfied. Could the 
>>>> secretaries confirm, please?
>>>>
>>>> Il giorno gio 15 feb 2018 alle ore 08:47 Tobias Nyholm <
>>>> tobias...@gmail.com> ha scritto:
>>>>
>>>>> Yeah, it has stalled for a few weeks. but we are working on it again. 
>>>>> The specification looks good, we are currently deciding on an upgrade 
>>>>> path 
>>>>> from HTTPlug. We have a proposal that we think will work. I've invited a 
>>>>> few to have a look on it (Sara included). If this small group think it is 
>>>>> fine I will publish it so every one could give their comments. 
>>>>>
>>>>> If no major issues are found I will move the PSR to review. 
>>>>>
>>>>> Den onsdag 14 februari 2018 kl. 13:11:46 UTC+1 skrev Barry vd. Heuvel:
>>>>>>
>>>>>> Apologies, I now see that PSR-18 is referenced in the Sunshine 
>>>>>> meetings (https://groups.google.com/forum/#!topic/php-fig/sjASl6ltjHI 
>>>>>> )
>>>>>>>
>>>>>>>
>>>>>>> PSR - 18 HTTP Client (*Abandoned*)
>>>>>>>
>>>>>>>- Tobias identified an issue and will be notifying the group to 
>>>>>>>source needed changes.
>>>>>>>   - Tobias is waiting on *Sara to offer feedback*.
>>>>>>>- This PSR needs 2 implementations to move forward.
>>>>>>>
>>>>>>> Status abandoned, is that supposed to be Draft? As you are 
>>>>>> discussing the issue with the group. Or are you in search of a new 
>>>>>> Editor?
>>>>>>
>>>>>>

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/6a82257a-3fd5-4c38-a374-ced008ddc27e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The progress of HTTP client

[Tobias Nyholm]

Yeah, it has stalled for a few weeks. but we are working on it again. The 
specification looks good, we are currently deciding on an upgrade path from 
HTTPlug. We have a proposal that we think will work. I've invited a few to 
have a look on it (Sara included). If this small group think it is fine I 
will publish it so every one could give their comments. 

If no major issues are found I will move the PSR to review. 

Den onsdag 14 februari 2018 kl. 13:11:46 UTC+1 skrev Barry vd. Heuvel:
>
> Apologies, I now see that PSR-18 is referenced in the Sunshine meetings (
> https://groups.google.com/forum/#!topic/php-fig/sjASl6ltjHI )
>>
>>
>> PSR - 18 HTTP Client (*Abandoned*)
>>
>>- Tobias identified an issue and will be notifying the group to 
>>source needed changes.
>>   - Tobias is waiting on *Sara to offer feedback*.
>>- This PSR needs 2 implementations to move forward.
>>
>> Status abandoned, is that supposed to be Draft? As you are discussing the 
> issue with the group. Or are you in search of a new Editor?
>
> Op woensdag 14 februari 2018 13:00:25 UTC+1 schreef Barry vd. Heuvel:
>>
>> Hello Tobias,
>>
>> Seeing as in the last two months, no new issues have arised, except for 
>> this PR discussing the formatting/necessity of a paragraph; 
>> https://github.com/php-fig/fig-standards/pull/980, is it possible to 
>> move this to review? 
>>
>> If there are no big objections and you are happy with the current 
>> document, a vote can be opened to move this to Review, right?
>>
>> Thank you for your work so far! No intention to rush this, but it seems 
>> to stall a bit recently, while overall looks very useful :)
>>
>> Op zaterdag 9 december 2017 14:00:18 UTC+1 schreef Niklas Keller:
>>>
>>> *Client:*
 You are just referring to an example that show that if you modify the 
 body you must to the same modifications on the headers. 

>>>
>>> Yes, I guess that's rather a specific question, as it should be clear to 
>>> other modifications. Should the `transfer-encoding: chunked` header be 
>>> removed by a client or not?
>>>  
>>>
 *Exceptions:*
 By "smaller issues" we mean: Things that do not stop you form sending a 
 request. If you are using the wrong HTTP version in the status line, that 
 does not stop the client from sending the request. The server may be able 
 to handle that anyways. So the client should not be "smart" and help you 
 to 
 fail early. 

>>>
>>> A wrong HTTP version isn't a small issue to me. Different HTTP versions 
>>> have a different message syntax and it's not wise just sending a wrong HTTP 
>>> version the client doesn't understand. The list of possible HTTP versions 
>>> is quite small, I think explicitly checking the version makes sense in 
>>> every client. In the worst case, sending another HTTP version the client 
>>> doesn't understand might result in a security vulnerability, because the 
>>> client interprets things the wrong way.
>>>  
>>>
 We do mention 1xx responses. They should be handled by the client.

>>>
>>> Yes, they're mentioned in the interface docs, but not in the 
>>> specification itself.
>>>  
>>>
 *RequestException*: 
 Hm, I do not think so. Why would you ever be interested in a Request 
 that was not sent? Im way more interested in the request that failed, 
 right?

>>>
>>> I don't have an immediate use case, but I can imagine that it could be 
>>> useful if you want to find the failed request within a set of requests. 
>>> Having the original request available would allow using ===, which 
>>> explicitly isn't possible with the current interface.
>>>
>>> On the other hand, the request will usually be available at the place 
>>> the exception is caught I guess.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/ac9c550a-8a37-4c63-b2c2-f2b413c59f44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The progress of HTTP client

[Tobias Nyholm]

Thank you. 

*Client:*
You are just referring to an example that show that if you modify the body 
you must to the same modifications on the headers. 

*Exceptions:*
By "smaller issues" we mean: Things that do not stop you form sending a 
request. If you are using the wrong HTTP version in the status line, that 
does not stop the client from sending the request. The server may be able 
to handle that anyways. So the client should not be "smart" and help you to 
fail early. 

We do mention 1xx responses. They should be handled by the client. 

*RequestException*: 
Hm, I do not think so. Why would you ever be interested in a Request that 
was not sent? Im way more interested in the request that failed, right?

//Tobias


Den fredag 8 december 2017 kl. 13:19:48 UTC+1 skrev Niklas Keller:
>
> I have just reviewed the current document, you can find my feedback below.
>
> *Client: *It specifies that a client that decodes a gzipped body must 
> remove the corresponding header. Does it also have to remove a chunked 
> encoding header? It's a requirement of the HTTP specification that a client 
> decodes chunked encoding.
>
> *Exceptions:* Smaller issues, like wrong HTTP versions, must not result 
> in an exception being thrown. This seems problematic to me. First of all, 
> there's no definition of "smaller issues". Next, I'd not classify a wrong 
> HTTP version as smaller issue. The semantics might change with newer HTTP 
> versions and a client that doesn't understand these shouldn't just send a 
> request with a newer HTTP version.
>
> Another point is the missing mention of 1XX responses here, as they can be 
> parsed into a valid HTTP response, but they're actually intermediate 
> responses.
>
> *RequestException + **NetworkException**: *getRequest() is documented to 
> return a request that might be different from the original request. Does it 
> make sense to add another method that returns the original request?
>

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/aa6fcf59-9322-4d0d-bb72-22c3841468e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The progress of HTTP client

[Tobias Nyholm]

Thank you for the review. 

Using `send` would make us incompatible with Guzzle and Buzz. It would 
force php-http's clients to have two methods doing the same thing. So we 
are more pragmatic here by using `sendRequest`. 

About `\Throwable`... Im not sure. I will do some research and make a PR to 
the specs. 
Thanks!

Den måndag 4 december 2017 kl. 14:44:41 UTC+1 skrev Woody Gilk:
>
> A couple of notes:
>
> public function sendRequest($request)
>
> Could this be made shorter, without losing meaning?
>
> public function send($request)
>
> Regarding the exception interfaces:
>
> interface ClientException extends \Throwable
>
> Why Throwable instead of Exception or RuntimeException?
>
> Everything else looks very straight forward!
>
> --
> Woody Gilk
> http://about.me/shadowhand
>
> On Mon, Dec 4, 2017 at 3:45 AM, Tobias Nyholm <tobias...@gmail.com 
> > wrote:
>
>> After some time of carefully reviewing and discussions on Github I want 
>> to let the mailing list know that we are soon comfortable with how PSR-18 
>> looks. We have documented the discussions in the meta document (
>> https://github.com/php-fig/fig-standards/blob/master/proposed/http-client/http-client-meta.md)
>>
>>  
>>
>> I invite you all to review the PSR and give some feedback. You will find 
>> the current specification here: 
>> https://github.com/php-fig/fig-standards/blob/master/proposed/http-client/http-client.md
>>
>>
>> Regards
>>
>> Tobias Nyholm
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "PHP Framework Interoperability Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to php-fig+u...@googlegroups.com .
>> To post to this group, send email to php...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/php-fig/35361389-c53a-4ee4-ac79-195402d9ab14%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/php-fig/35361389-c53a-4ee4-ac79-195402d9ab14%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/eb8cf965-ad99-4170-befc-8231ff190b13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

The progress of HTTP client

[Tobias Nyholm]

 

After some time of carefully reviewing and discussions on Github I want to 
let the mailing list know that we are soon comfortable with how PSR-18 
looks. We have documented the discussions in the meta document (
https://github.com/php-fig/fig-standards/blob/master/proposed/http-client/http-client-meta.md)

 

I invite you all to review the PSR and give some feedback. You will find 
the current specification here: 
https://github.com/php-fig/fig-standards/blob/master/proposed/http-client/http-client.md


Regards

Tobias Nyholm

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/35361389-c53a-4ee4-ac79-195402d9ab14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Should new PSRs support PHP5?

[Tobias Nyholm]

Hey. 

While reviewing PSR-18 I found a suggestion to make our base exception to 
implement \Throwable. So, should new PSRs support PHP 7 only or do we still 
need PHP 5 support?

Like someone said, "PHP5 is dying, just kill it already". I like to agree 
with that. But at the same time, I do not what the guzzle/buzz community to 
choose between implementing this PSR or supporting PHP5. 

I would like the core committee to give me (and other authors of new PSRs) 
a unified recommendation: Should new PSRs support PHP5 or not? 

// Tobias Nyholm

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/e5c6ab88-9576-4ae1-835e-d68b458243d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR for HTTP clients

[Tobias Nyholm]

Thank you for all your comments and suggestions. I will bring these to the 
work group if/when it is approved. 

I lean towards NEVER throw exceptions. 

And about the exceptions: I agree, they could maybe need some renaming and 
updates to be more clear. 



On Tuesday, July 11, 2017 at 11:18:30 PM UTC+2, Matthieu Napoli wrote:
>
> I have to agree with Larry, having the behavior of a standard depend on 
> some configuration is risky. If the goal of the PSR is to be used by 
> libraries or frameworks (not end users) then it's fine to force a choice 
> IMO.
>
> I have minor comments about the proposal, maybe it's too early to get into 
> details and create a proper thread but I would suggest making the 
> exceptions clearer:
>
>  * Exception for when a request failed. * Examples: *  - Request is 
> invalid (eg. method is missing) *  - Runtime request errors (like the 
> body stream is not seekable)interface RequestException extends Exception
>
>
> How about InvalidRequestException? (I would suggest InvalidRequest but it 
> would be a waste of time :p)
> We need to make it clear that the HTTP request did not fail, it's the 
> Request object that was invalid.
>
>  * Thrown when the request cannot be completed because of network issues. * 
> There is no response object as this exception is thrown when no response has 
> been received. * Example: the target host name can not be resolved or the 
> connection failed.interface NetworkException extends Exception
>
>
> NetworkErrorException? OK maybe this one is too much (NetworkError would 
> be better but…)
>
> And as said above HttpException should probably be removed entirely?
>
> Matthieu
>
> Le mardi 11 juillet 2017 18:33:15 UTC+2, Larry Garfield a écrit :
>>
>> I'm inclined to agree here.  Error handling that may change based on some 
>> config not available to me in local scope, like PDO does, is a design flaw, 
>> as I then have to account for both possible error flows.
>>
>> I could be argued in favor of exceptions always or exceptions never (I'm 
>> leaning exceptions on all 4xx/xx right now, but could be convinced 
>> otherwise), but "exceptions sometimes" doesn't seem like a good choice.
>>
>> That said, that's a detail that doesn't block officially forming the WG; 
>> I'm +1 on approving this as a WG to hash out exactly those sorts of details.
>>
>> --Larry Garfield
>>
>> On 07/11/2017 11:12 AM, Josh Di Fabio wrote:
>>
>> Right, I see; I saw the *HttpException* class but I missed that it *MUST 
>> NOT be thrown when using the client's default configuration.* 
>>
>> Having said that, I think the fact that the behaviour of *sendRequest()* 
>> varies 
>> based on some configuration which isn't available via the interface is 
>> actually worse than always throwing. Given that most people will be 
>> injecting their *HttpClient* instance into other objects and probably 
>> passing one instance around to multiple classes, the code which is calling 
>> *sendRequest()* won't generally have visibility over how the client is 
>> configured, so we'll have to be super defensive when calling the client to 
>> be sure we handle 4xx and 5xx responses correctly: 
>>
>> try {
>> $rep = $client->sendRequest($req);
>> } catch (HttpException $e) {
>> $rep = $e->getResponse();
>> }
>>
>> It should either always throw or never throw. The behaviour of redirects 
>> should also be consistent or configurable via the interface or else 
>> autowiring will be useless for instances of *HttpClient*.
>>
>> On Tue, Jul 11, 2017 at 4:51 PM <tobias...@gmail.com> wrote:
>>
>>> I think I've been unclear or you misread something. 
>>> A HTTP client MUST NOT throw exceptions for any response. 
>>>
>>> So I very much agree with you. 
>>>
>>>
>>> On 11 Jul 2017, at 17:45, Josh Di Fabio <joshd...@gmail.com> wrote:
>>>
>>> This looks pretty good, but I don't like exceptions for 4xx and 5xx 
>>> responses, which smells of exceptions for flow control. Within the context 
>>> of HTTP there is nothing exceptional about 4xx and 5xx responses. Rather, 
>>> whether a certain response status is considered exceptional depends on the 
>>> context of the caller. For example, in many contexts a 3xx response would 
>>> be unexpected but a 404 response would not. Instead of throwing, the client 
>>> should simply return the response.
>>>
>>> On Tue, Jul 11, 2017 at 12:48 PM Alessandro Lai <alessand...@gmail.com> 
>>> wrote:
>>>
>>>&

Re: PSR for HTTP clients

[tobias . nyholm]

I think I've been unclear or you misread something. 
A HTTP client MUST NOT throw exceptions for any response. 

So I very much agree with you. 


> On 11 Jul 2017, at 17:45, Josh Di Fabio <joshdifa...@gmail.com> wrote:
> 
> This looks pretty good, but I don't like exceptions for 4xx and 5xx 
> responses, which smells of exceptions for flow control. Within the context of 
> HTTP there is nothing exceptional about 4xx and 5xx responses. Rather, 
> whether a certain response status is considered exceptional depends on the 
> context of the caller. For example, in many contexts a 3xx response would be 
> unexpected but a 404 response would not. Instead of throwing, the client 
> should simply return the response.
> 
>> On Tue, Jul 11, 2017 at 12:48 PM Alessandro Lai <alessandro.la...@gmail.com> 
>> wrote:
>> Very good suggestions.
>> Also, it's very pleasant to see a PSR pushed this way and backed from the 
>> start by a working lib and all the interestend players. Really good job!
>> 
>> 
>> Il giorno lunedì 10 luglio 2017 00:38:32 UTC+2, Larry Garfield ha scritto:
>>>> On 07/07/2017 12:20 PM, Tobias Nyholm wrote:
>>>> Excellent questions. Thank you. 
>>>> 
>>>> The buy-in would be the same for every PSR, wouldn't it? Libraries do not 
>>>> want to depend on an implementation or provide an implementation 
>>>> themselves. They want the user to decide if a highly flexible client 
>>>> (Guzzle) or a lightweight/fast client (php-http/curl-client). (Source: 
>>>> https://github.com/joelwurtz/http-client-benchmark). Also, as you probably 
>>>> noticed, there are representatives from all PSR7 compliant HTTP clients in 
>>>> the workgroup. 
>>> 
>>> That last point was what I was getting at, thank you.  By buy-in, I mean 
>>> "do we have an indication that the major HTTP clients are going to adopt 
>>> it?"  It sounds like the answer is a loud "yes", which is great to see.
>>> 
>>>> The simplest answer of async or not is: There is not PSR for Promises yet. 
>>>> I do not think the PSR for HTTP clients should define what the industry 
>>>> standard for a Promise should be. I do also not think we should wait with 
>>>> a PSR for HTTP clients until (if ever) a PSR for promises has been 
>>>> released. 
>>>> 
>>>> We, php-http team, have followed discussions in 
>>>> https://github.com/async-interop that sadly has been put on hold. 
>>> 
>>> A fair reason, thanks.  It may be worth mentioning in the metadoc, 
>>> including what a future Async version MIGHT look like if/when a Promises PS 
>>> happens.  (You don't need to implement it, just show that it could still be 
>>> implemented.)
>>> 
>>> --Larry Garfield
>>> 
>> 
>>>>> On Friday, July 7, 2017 at 6:58:36 PM UTC+2, Larry Garfield wrote:
>>>>> The key for me is if the various HTTP clients have buy-in to implement 
>>>>> the spec once completed.  Is that the case?
>>>>> 
>>>>> I would also ask why this is just for sync HTTP clients, not async.  
>>>>> There's plenty of use cases for the latter.  That may be scope creep, but 
>>>>> I feel it's worth asking.
>>>>> 
>>>>> --Larry Garfield
>>>>> 
>>>>>> On 07/07/2017 03:47 AM, Tuomas Koski wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> +1 for first creating working stuff and later doing effort to make it a 
>>>>>> good standard. Way better approach than the other way round :)
>>>>>> 
>>>>>> Great work.
>>>>>> 
>>>>>> Cheers and great weekends!
>>>>>> --
>>>>>> Tuomas
>>>>>> 
>>>>>> 
>>>>>> On Thu, Jul 6, 2017 at 11:04 PM, Cees-Jan Kiewiet <cees...@gmail.com> 
>>>>>> wrote:
>>>>>>> Hey,
>>>>>>> 
>>>>>>> This looks interesting, would have to study this in detail but I do 
>>>>>>> like the simplicity from a quick read through.
>>>>>>> 
>>>>>>> Cees-Jan
>>>>>>> 
>>>>>>> 
>>>>>>>> On Thu, Jul 6, 2017 at 6:08 PM, Tobias Nyholm <tobias...@gmail.com>
>>>>>>>>wrote:
>>>>>>>> He

Re: PSR for HTTP clients

[Tobias Nyholm]

Excellent questions. Thank you. 

The buy-in would be the same for every PSR, wouldn't it? Libraries do not 
want to depend on an implementation or provide an implementation 
themselves. They want the user to decide if a highly flexible client 
(Guzzle) or a lightweight/fast client (php-http/curl-client). (Source: 
https://github.com/joelwurtz/http-client-benchmark). Also, as you probably 
noticed, there are representatives from all PSR7 compliant HTTP clients in 
the workgroup. 

The simplest answer of async or not is: There is not PSR for Promises yet. 
I do not think the PSR for HTTP clients should define what the industry 
standard for a Promise should be. I do also not think we should wait with a 
PSR for HTTP clients until (if ever) a PSR for promises has been released. 

We, php-http team, have followed discussions 
in https://github.com/async-interop that sadly has been put on hold. 


On Friday, July 7, 2017 at 6:58:36 PM UTC+2, Larry Garfield wrote:
>
> The key for me is if the various HTTP clients have buy-in to implement the 
> spec once completed.  Is that the case?
>
> I would also ask why this is just for sync HTTP clients, not async.  
> There's plenty of use cases for the latter.  That may be scope creep, but I 
> feel it's worth asking.
>
> --Larry Garfield
>
> On 07/07/2017 03:47 AM, Tuomas Koski wrote:
>
> Hi, 
>
> +1 for first creating working stuff and later doing effort to make it a 
> good standard. Way better approach than the other way round :)
>
> Great work.
>
> Cheers and great weekends!
> --
> Tuomas
>
>
> On Thu, Jul 6, 2017 at 11:04 PM, Cees-Jan Kiewiet <cees...@gmail.com 
> > wrote:
>
>> Hey, 
>>
>> This looks interesting, would have to study this in detail but I do like 
>> the simplicity from a quick read through.
>>
>> Cees-Jan 
>>
>>
>> On Thu, Jul 6, 2017 at 6:08 PM, Tobias Nyholm <tobias...@gmail.com 
>> > wrote:
>>
>>> Hey.  
>>>
>>> Im a co-creator of HTTPlug and a maintainer of a number of API clients. 
>>> I would really like to see a PSR for synchronous HTTP clients. The HTTPlug 
>>> has created a "meta-standard" which has been stable for 18 months now. We 
>>> believe it is a really good interface and would like it (or something 
>>> similar) to be an official PSR. 
>>>
>>> I would ask the Fig for an entrance vote.
>>>
>>> *Here is a first idea: *
>>> PSR: 
>>> https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client.md
>>> Meta: 
>>> https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client-meta.md
>>>
>>> *Workgroup*:
>>> These people has been contacted and said they are interested in 
>>> participating in a workgroup. 
>>>
>>>- Tobias Nyholm
>>>- Sara Golemon (cc)
>>>- Matthew O'Phinney (cc) (Maybe)
>>>- Mark Sagi-Kazar 
>>>- Jermey Lindstrom
>>>- David Buchmann
>>>- Joel Wurtz
>>>- Simon Asika
>>>- Christian Lück
>>>- David De Boer
>>>
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "PHP Framework Interoperability Group" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to php-fig+u...@googlegroups.com .
>>> To post to this group, send email to php...@googlegroups.com 
>>> .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/php-fig/0db70a2c-d528-44df-b7f5-62387eb67872%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/php-fig/0db70a2c-d528-44df-b7f5-62387eb67872%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "PHP Framework Interoperability Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to php-fig+u...@googlegroups.com .
>> To post to this group, send email to php...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/php-fig/CAPY1sU_e%2BwDVGGm-3VGZzjNfPUpAyA3Ng6tk04%2BdtLcADMqAwA%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/php-fig/CAPY1sU_e%2BwDVGGm-3VGZzjNfPUpAyA3Ng6tk04%2BdtLcADMqAwA%40mail.gmail.com?utm_medium=email_source=footer>.
>&g

Re: [VOTE] First Core Committee Elections

[Tobias Nyholm]

Tobias Nyholm 
Beau Simensen
Chris Tankersley
Graham Daniels
Larry Garfield
Lukas Kahwe Smith
Marc Alexander
Matthew Weier O’Phinney
Samantha Quiñones
Sara Golemon


// Tobias 

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/1989c3d5-7a7b-418a-8627-3ba08de52f02%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[CC] [About Candidate] Tobias Nyholm

[Tobias Nyholm]

 

Hey. 

For those of you who do not know me, I'm Tobias Nyholm from Stockholm. I 
started doing serious of open source development 4 years ago. I've created 
libraries like php-cache, HTTPlug, LinkedIn API and 
HappyrDoctrineSpecification. I'm currently maintaining PHP-Geocoder, 
MailgunApi, JMSTranslatorBundle and Guzzle. I've also done some large 
contributions to KNPGithubApi, SparkpostApi, Swap, Payum, SymfonyWorkflow 
and lots of smaller ones. 

I'm currently preparing two PSRs related to HTTP and cache. 


I want to be involved in the Fig because I like what the organization has 
produced so far and I really like the new Fig 3.0 structure. There is a lot 
of people that are active here that are a lot smarter than I am. What I 
believe I can bring to the core committee is a knowledge of the community. 
The part of the community that barley heard about the Fig, the part that 
never goes to conferences, the part that just want to get their problem 
solved. I've gain that knowledge by reading a lot of code and creating 
loads of PRs trying to bring SOLID thinking and package abstractions into 
third party libraries. I've heard all variations of "This does not *feel* 
right" even though I argue with reasons of computer science. I've learned 
that it does not matter how correct your solution is if it comes with a bad 
developer experience. In such situations I believe Im good at finding 
compromises that makes all parties happy. 



// Tobias

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/b7dcfba9-c618-42a7-94da-ae50d71da99c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[CC] [Nomination Request] Tobias Nyholm

[Tobias Nyholm]

I'm happy to accept the nomination. 
Thank you.

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/93c048a9-7074-4f70-9bef-b078406c2fce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.