--
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+unsubscribe@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.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAPY1sU_e%2BwDVGGm-3VGZzjNfPUpAyA3Ng6tk04%2BdtLcADMqAwA%40mail.gmail.com.
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/CAAND7_93GNv9R0_e%3DU-e%2B%3DfGWh%3D99hHR5RtkQb2Nde%2BvaSj5vA%40mail.gmail.com.
Cees-Jan
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.
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.
--
Cheers,--TuomasHumap Software Ltd
http://humapsoftware.com
Twitter: @humapsoftware
LinkedIn: https://www.linkedin.com/company/humap-software-ltd
Facebook: http://facebook.com/humapsoftware/
Instagram: @humapsoftware
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/6ac1a1f0-f62b-42e3-912c-74faa3e28950%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/f47fa29c-7176-44a5-bd0c-436df87f34a6%40googlegroups.com.
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/iFZF6T9L2zA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAKiSzdBMhrjab-VzrASmu%2B5audhGt-KEbrsx7TM%2BBSwPgbwmcg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/6383CD29-BA16-4253-91C3-72CBDB2EA9F6%40gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAKiSzdDmRdzeCjWghZSWpeHLskpUg-cq5xu%2B485GoAdyo7-%2BNg%40mail.gmail.com.
* 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
* 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
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/5aa5e0d1-81db-4ee0-a618-a7fb6a2b2a86%40googlegroups.com.
So given the unanimous support for the HTTP Client and the current implementations, the only actual point of discussion is the throwing of Exceptions on 4xx/5xx responses, right?As a library maintainer, I'd like to rely on the behavior of the Client, so either ALWAYS or NEVER, not depending om some hidden config. Otherwise I'd have to check both cases again every time.And in that case my preference would be to NOT throw exceptions on 4xx/5xx errors.Hope this will make it to a real PSR soon :) Good job!
--
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/8cd91c71-0738-4aee-8391-54cff756051b%40googlegroups.com.