Support Cancellation of Request

[bbrandt]

We should pass a CancellationToken through to the HttpClient's SendAsync() method. Who do you think should own the CancellationToken, or where should it originate?

Some options:

• Provide overloads for all async methods that allow a CancellationToken to be passed in.
• Each ResourceGroup obtained from SeqConnection owns their own CancellationToken to cancel all requests currently active for that ResourceGroup. Cancel() method on the resource group would cancel the/all active requests for that resource group.
• SeqConnection has a CancellationToken that gets passed to all requests. SeqConnection would have a Cancel() method that cancels the/all active request.

If we intend the library to eventually support concurrent operations, then option 1 is the only logical choice. If we think the library will always be intended for single-threaded use, then maybe the last option is OK.

[nblumhardt]

I think now we've set off down the concurrent-use path, option 1 does seem to make the most sense. Using a defaulted parameter might work and keep the proliferation of methods under control...

[bbrandt]

I'm good with that.

[nblumhardt]

This is included v5 of the API client.