Mark, Have a look look at:
src/test/java/org/apache/ahc/AsyncHttpClientTest.java The doConnection() is pretty much an example. Basically, you set up an implementation of the AHCCallback to notify you of a response, set up a HttpRequestMessage for your URI, and then make the call to ahc.connect() and ahc.sendRequest(request). However, I am probably going to get rid of the direct access to the HttpRequestMessage and have folks just set/get on the AsyncHttpClient object, which will act as a proxy to the HttpRequestMessage. This will simplify things. I will also probably get rid of the sendRequest() and have everything happen in the connect() method as a single async call - again to simplify its use. There are a few TODOs I am currently working on. 1) I am working on the HTTP/1.1 chunking (hopefully be done today). 2) Need to handle the HTTP/1.1 100 Continue (should be easy to do). 3) Auto-handle 301 Redirect. 4) Handle proxies. 5) A good timeout implementation. Not sure whether to use the sessionIdle() or use a concurrent timer. Since its a single request/response, sessionIdle() may work fine. 6) Possibly allow handling of streams for very large packets (right now it pulls the entire response into memory - which works for 99% of the use cases). But it would be nice to allow people to get their data moved in chunks. I probably need some input on implementing this efficiently...but I think this is the lowest priority item. 7) Finer grained control over the threading model. Basically allow people to tweak the thread pool or pass in their own to use. What currently works: A) HTTPS/SSL/HTTP submission and response B) Cookie handling C) Header handling D) Parameter handling (web parameters) E) All HTTP request types (GET, POST, etc) D) Text and Binary responses As for the donation's being up to Apache spec...I am already an Apache guy (CLA already on file) and it's coming from Apache into Apache ;-) AFICT I have all of the necessary headers are in the source - hopefully I haven't missed anything. We probably just need to rename the packages, etc, to something more meaningful/appropriate to Mina. Thanks, Jeff Mark wrote: > will do. BTW, do you have any code that I could use in the "mina-examples" > component? I have the code you wrote up to MINA 2.0 compliance, but I want > to provide a sample program as well. > > Thanks, > Mark > > On 8/21/07, Jeff Genender <[EMAIL PROTECTED]> wrote: >> Let me know when you have moved the code over so I can start submitting >> patches to it since I am developing against the Geronimo sandbox now. >> >> Thanks, >> >> Jeff >> >> Mark wrote: >>> I created a mina-httpclient component on the trunk. Just working things >>> out, along with an example and I will check things in. >>> >>> >>> On 8/21/07, Mike Heath <[EMAIL PROTECTED]> wrote: >>>> This sounds awesome! >>>> >>>> I would like to see this as the client part of AsyncWeb for two >> reasons. >>>> First it seams to be a natural fit. Second it might give us a little >>>> more incentive to finally get AsycWeb moved over to MINA. >>>> >>>> -Mike >>>> >>>> Jeff Genender wrote: >>>>> Hi, >>>>> >>>>> First, I want to say that I am a big fan of Mina. For those who don't >>>>> know me (which is everyone), I am a committer on Geronimo and have had >>>>> several people ask about an async http client API to use with our NIO >>>>> clients with comet for the 2.0 Geronimo server. We have had folks who >>>>> want to be able to do HTTP calls to 3rd party servers from >> servlets/web >>>>> apps to get content, and not tie up a thread while its doing its >> thing. >>>>> So I decided to try to whip together an API that was similar to >> Commons >>>>> HttpClient, fully asynchronous, but based on Mina...and I think I have >>>>> 80-90% of it completed. It is here: >>>>> >>>>> http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient >>>>> >>>>> For what it's worth...it doesn't seem appropriate for Geronimo. So I >>>>> would like to donate it to Mina. Please have a look at it and give me >>>>> feed back for if I have gone down the right path. It can be enhanced >>>>> greatly as this is just a start, but I think it can be very useful and >>>>> become a powerful API with everyone moving to NIO. >>>>> >>>>> Don't hold back any comments ;-) I would really like to see an API >> like >>>>> this and I believe Mina is just perfect for this. >>>>> >>>>> Please let me know what you think..and if you don't think its right >> for >>>>> Mina..thats ok too ;-) But getting your feedback would be best for >>>>> me...and making this a community project is even better ;-) >>>>> >>>>> Jeff >>>>> >>> > > >
