Dear Wiki user, You have subscribed to a wiki page or wiki category on "Jakarta-httpclient Wiki" for change notification.
The following page has been changed by RolandWeber: http://wiki.apache.org/jakarta-httpclient/HttpAsyncThreadingDesign The comment on the change is: order of steps ------------------------------------------------------------------------------ The following figure shows the steps required to execute a request. attachment:responsibilities.png + [[BR]] + ''add 'close' or 'consume' as a step?'' Steps that necessarily have to be executed by an application thread are shown to the left. Only the application can decide which request should be executed and what to do with the response. To the right are steps that have to be executed by a background thread. - Sending of the request and waiting for the response is shown there since it is the purpose + Sending of the request and waiting for the response is there since it is the purpose of HttpAsync to offload such tasks from applications. Notification for incoming responses has to be triggered by the thread that was waiting for the response. - Receiving the response header is assigned to the background thread too, because an API would + Receiving the response header is assigned to the background thread too, because + it is a precondition for notification, as explained below. - be very inconvenient to use if the status code of a response was not known at the time of - notification. The steps in the middle column can reasonably be assigned to either side. ''To be done:'' * application code vs. library code - * order of steps + + + The order of the steps from top to bottom is roughly chronological, + but some are independent and can be executed in a different order. + For example, a request must be created before it can be preprocessed. + But the connection for sending the request can be allocated before + or after preprocessing, or even before the request is created. + The table below shows the sequences in which some of the steps have + to be executed, one sequence in each column. + Postprocessing has to be done before chasing redirects, since there might + be cookies in the response that need to be stored for the followup request. + Reading the response header should be done before notification, because a + notification before status code and headers of the response are known would + be very inconvenient to use. The other sequences should be obvious. + + ||<^> create request[[BR]] preprocess[[BR]] send request[[BR]] receive response header[[BR]] postprocess[[BR]] interpret final response[[BR]] ||<^> allocate connection[[BR]] send request[[BR]] receive response header[[BR]] read response body[[BR]] release connection[[BR]] ||<^> receive response header[[BR]] notify[[BR]] handle notification[[BR]] ||<^> receive response header[[BR]] postprocess[[BR]] chase redirects[[BR]] || == API == ''describe the interfaces defined for the HttpAsync API'' + == Blocking IO Implementation == - == Initial Design == + === Initial Design === ''describe the design chosen for the initial implementation'' - == Alternative Design == + === Alternative Design === ''describe a design not chosen for the initial implementation'' --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
