[
https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721864#action_12721864
]
Mike Cumings commented on HTTPCLIENT-854:
-----------------------------------------
@Oleg: Sure, I can restructure the code a bit to make it a bit more of an
add-on. The use of interfaces everywhere sure makes it difficult to maintain
API stability. There's no way I could possibly justify the time to build up a
new API on top of HttpCore NIO. I agree that this is an uncommon use scenario
(though I have seen requests for this made in the past on the list). Knowing
that, I want to leverage as much existing code as possible to prevent this code
path from getting left behind, stale, etc.
@Sam: I couldn't find a nomenclature that I liked at all. Since I'm equally
unhappy with anything I've come up with, I have no problem switching over to
"deferred".
I'm running out of time to dedicate to this but what I'm thinking I'll do is:
- Add an interface ("SplitExecutionHttpClient", "SerialHttpClient", ...?) which
defines the executeRequest(...) method.
- Implement the above interface in AbstractHttpClient.
- Add an interface following the same naming scheme for
"SplitExecutionRequestDirector"
- Implement the SERD interface in the DefaultRequestDirector
- Update the AbstractHttpClient to reference the DefaultRequestDirector using
the new interface when split exec is desired
- Update the HttpCore code to follow the new naming scheme
Sound acceptable?
> RFE: Provide mechanism to allow request transmission and response reception
> to be performed independently
> ---------------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-854
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-854
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 4.0 Final
> Environment: All
> Reporter: Mike Cumings
> Priority: Minor
> Fix For: Future
>
> Attachments: HTTPCLIENT-854_httpclient_2009-06-18_1.patch,
> HTTPCLIENT-854_httpcore_2009-06-18_1.patch
>
>
> The HttpClient API currently provides for the execution of a request via the
> HttpClient.execute(...) methods. These methods all send the request and then
> block until the response has been received. This precludes the user of the
> API from being able to send the request, perform some additional work, then
> come back and block on the request. This style of processing is very
> desirable for implementation of HTTP-based protocols such as
> Bidirectional-streams Over Synchronous HTTP (BOSH). This capability is also
> closely related to HTTPCLIENT-258, support for HTTP 1.1 pipelining.
> The current code base (4.0) currently utilizes
> org.apache.http.impl.client.DefaultRequestDirector.execute(...) to transmit
> requests. This method contains a retry loop which blocks on and then
> examines the response from the remote server. When success is detected, it
> cleans up and returns the response instance. Requests are sent using an
> HttpResponseExecutor instance. These classes support the ability to
> separately doSendRequest() and doReceiveResponse().
> Please expose the ability to leverage this functionality outwith the retry
> loop but including the existing routing and authorization capabilities, where
> possible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
