forked from php-fig/fig-standards
-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added note about async non-goal #31
Closed
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should define neither promises nor an async-compatible version of PSR-7
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you tell me why PSR-7 is not async?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For example, because
getContents()
requires blocking, as does__toString()
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is an implementation detail. ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it's not. Blocking is an absolute no-go in fully async apps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nowhere in the PSR-7 specification does it say that
getContents
has to use__toString
. (In factgetContents
and__toString
has different behaviours. ) Nor does it say that it has to be blocking.Im saying that you can implement PSR-7 with non-blocking. It is not a limitation in the interface but in the implementations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Of course it doesn't say it has to be blocking, as that's the default for any IO operation in PHP. It has to be blocking, because the interface requires an immediate return on a call to these methods.
Could you try to elaborate how that should be possible? See what React did.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @Nyholm here, the text LGTM and the discussion whether PSR-7 can be used in an async context is both an implementation detail and out of scope here 👍
(@kelunik IMO the last link adds little value here and its motivation is better described in the documentation (https://github.com/reactphp/http#request), rather than the code. As an alternative, PSR-7 does not prevent you from buffering the whole message in memory, in which case all accessors can be used perfectly fine even in an async program 👍)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@clue It doesn't really matter as an async client is out of scope in any way, regardless of the wording here.
I completely understand the motivation behind that, but it doesn't really matter either. If it could be implemented sanely, I'm pretty sure you guys would have done that. It doesn't prevent buffering, of course not, but we both know that it doesn't fit for all bodies and is the exact reason why the request body isn't represented as a string, but a stream.