hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Cumings (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCLIENT-854) RFE: Provide mechanism to allow request transmission and response reception to be performed independently
Date Fri, 19 Jun 2009 16:32:07 GMT

    [ 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message