converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 6:||Line 6:|
|Line 9:||Line 9:|
|Line 14:||Line 14:|
| * [wiki:Self:UseCases/SingleAsyncRequest single asynchronous request]
* [wiki:Self:UseCases/SingleAsyncRequestNotify single asynchronous request with notification]
* [wiki:Self:UseCases/AsyncFireAndForget send a single request asynchronously, forget about the response]
* [wiki:Self:UseCases/MultiAsyncRequests multiple asynchronous requests]
| * [[UseCases/SingleAsyncRequest|single asynchronous request]]
* [[UseCases/SingleAsyncRequestNotify|single asynchronous request with notification]]
* [[UseCases/AsyncFireAndForget|send a single request asynchronously, forget about the response]]
* [[UseCases/MultiAsyncRequests|multiple asynchronous requests]]
|Line 22:||Line 22:|
|The background thread that would otherwise [wiki:Self:UseCases/SingleAsyncRequestNotify notify]||The background thread that would otherwise [[UseCases/SingleAsyncRequestNotify|notify]]|
Use Case: Asynchronous Sequence of Requests
I want to send a request over a connection, without blocking the application.
If the response requires a follow-up request, for example to perform authentication or chase a redirect, I want that to be generated and sent automatically.
I want a notification when the final response is available for my application.
Related / Out of Scope
The problem with this use case is to assign the responsibility for generating follow-up requests. The background thread that would otherwise notify the application could generate the follow-up request in most cases. A noteworthy exception is authentication if user interaction is required to obtain the credentials, for example from a password dialog. The usual background threads must remain available for handling asynchronous requests and responses, they can not block in this situation. Even if that is not the case, other requests or responses may be delayed if follow-up requests are created by the background threads. Some possible solutions are:
- have the background threads create the follow-up requests and live with the consequences
- use extra background threads to generate follow-up requests
- require an application thread to generate follow-up requests and make it easy for the application developer to provide it