-
Notifications
You must be signed in to change notification settings - Fork 412
Add :async-future as an option for async request processing #516
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
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 left a couple of comments, I see this is a draft though, so I didn't know if it's ready for review.
src/clj_http/client.clj
Outdated
[req [respond raise]] | ||
(if (opt req :async) | ||
[req & [respond raise]] | ||
{:pre [(not (and (:async req) (:async-future req)))]} |
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.
These should use (opt req :async)
and (opt req :async-future)
so they support the optional ?
suffix
src/clj_http/client.clj
Outdated
(opt req :async-future) | ||
(let [basic-future (org.apache.http.concurrent.BasicFuture. nil)] | ||
(request (-> req | ||
(dissoc :async-future) |
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.
In order to avoid having multiple options I think this should be:
(dissoc :async-future) | |
(dissoc :async :async? :async-future :async-future?) |
Sorry for the delay, I've taken your suggestions -- it is ready for review now :) |
One thing I really don't like about the approach here is that there is no way to generalize this functionality to For that reason, I'm going to close this PR. |
Solves #512.
Notes for Reviwer:
I chose to add a separate option
:async-future
instead of changing the existing:async
implementation to avoid breaking API changes.