Alan D. Cabrera wrote: > > On Mar 3, 2008, at 12:26 PM, Sangjin Lee wrote: > >> We have been making a number of changes on the Geronimo sandbox side >> for the >> AsyncHttpClient. We've been meaning to move them over, but the pent-up >> changes have grown to quite a few. I haven't had time to sit down and >> analyze whether certain bug fixes are applicable for the asyncweb >> codec. I >> hope I'll be able to do that some time this week or next week at the >> latest. >> Just a heads up for you... > > Has the merge for Geronimo AHC been completed on the Mina side yet? > IIRC, someone was still integrating the AsyncWeb codec.
No it's still in limbo. I haven't had as much time as I anticipated to work on this. On top of the fact that is taking much more time than I originally estimated that it would (doesn't it always though?) The biggest problem is that AHC uses the HttpRequest object to store the state of the request, the future, the callback, etc. This doesn't work at all with the AsyncWeb Commons code. Unfortunately, this also affects almost everything in AHC so it's not something that can be easily changed in small steps. In my local working copy, I've moved everything over to use the AsyncWeb commons HttpRequest and I've moved all the state information into the AHC ResponseFuture object. This has, of course, required API changes. Everything compiles, but nothing works and it will take a lot more effort to make it work. I'm not sure how best to proceed. We need to port support for HTTP proxy and HTTP auth to AsyncWeb Commons. There are also a lot of AHC tests that I think would be valuable to have in AsyncWeb Commons. After that, honestly, I think that we should focus our efforts on the new client API's that are being discussed. It doesn't make sense to port AHC over to use AsyncWeb Commons if were only going to go and revamp the API anyway. We can still capitalize on a lot of the AHC work in AsyncWeb Commons and this can be done incrementally. Thoughts? -Mike
