-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Deprecate Client
in favor of SyncClient
#54
Comments
I'd be completely fine with this change, though it probably would be best to wait until there is more than just the blocking |
Sean's comment on #120 makes me think it'd be a good idea to do this rename prior to 1.0 even if there is only one kind of client just so the name for the sync client won't need to change between 1.0 and 2.0. There will be more people with existing code using whatever the sync client is called then than there are now. |
@seanmonstar Do you have a roadmap for stablizing the async stuff? |
@knight42 part of the issue is that futures and tokio are unstable, so that's the first blocker to being able to stabilize the async API in reqwest. |
The default |
Could we move away from naming one of the clients "defacto-default"? i.e. Calling them:
reqwest::AsyncClient
andreqwest::Client
implies that the sync client is the default and async is somehow special and warrants investigation.Using
reqwest::AsyncClient
andreqwest::SyncClient
would be equally ergonomic, and allocates zero preference towards either implementation.As per our exchange on reddit, we could do the following:
P.S. As long as there isn't much opposition to this idea, this change is easy enough, I'm happy to do it if needed.
The text was updated successfully, but these errors were encountered: