Options to cancel a Task.

[fabianfett]

Hi, the AsyncHTTPClient currently has an interface, that makes the consumer choose between

1. shorthands to get/post/execute, where the consumer doesn’t have to implement the delegate but has no chance to cancel a task
2. full access to the task but one has to implement the delegate.

I would like to be able to cancel my request but I don’t want to implement the delegate protocol myself. Currently the ResponseAccumulator is an internal class and therefore can’t be used by a consumer.

Would it be possible to make the ResponseAccumulator public? Or can we build an execute method that doesn't need a delegate but returns a Task instead of a Response?

Whatever the preferred way is, if there is a decision on how to move forward, I'd be interested in creating a potential PR.

[Yasumoto]

Returning a Task seems like a better interaction than having to plug in your own ResponseAccumulator, but I'd be interested to hear if you've had the chance to try that out!

[artemredkin]

There is a small problem with returning a task - it will change public API :(, though I do agree that its a better solution...

[fabianfett]

@artemredkin So what's your preferred way forward? Are you open for a breaking change when switching to 2.0? Though I'm aware that we just recently got to 1.0. What do we want to do in the meantime? Exposing a second endpoint?

[vkill]

ResponseAccumulator public and final +1

[krzyzanowskim]

ResponseAccumulator public and not final +1

[Lukasa]

I think making ResponseAccumulator public is a good idea. I'm inclined to begin making it public and not open and to give it no public API surface area.

I believe @krzyzanowskim wants ResponseAccumulator to be non-final to adapt it to a streaming model. I don't think that's a particularly good idea: the streaming use-case should be served by HTTPClientCopyingDelegate once #154 ships.

[weissi]

@fabianfett can we close this issue?

[fabianfett]

@weissi Yes!