Sounds good to me. The codec has evolved quite a bit, so yeah, we'd need to pay attention to the codec to make sure all the features are properly migrated... Please let me know how I can participate in this effort. We'll open new JIRA issues as we identify individual tasks, no? Thanks, Sangjin
On Feb 4, 2008 4:45 PM, Mike Heath <[EMAIL PROTECTED]> wrote: > I've been looking into merging > http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/ > into http://svn.apache.org/repos/asf/mina/asyncweb/trunk/client/ and I'm > trying to figure out the best way to proceed. Here are some of the pain > points I see: > - The only redeeming quality about the AsyncWeb client is that it uses > the AsyncWeb codec. > - There are a few things in AHC that duplicate functionality already > available in MINA (timeouts for example) > - The AHC codec and the AsycnWeb codec have diverged quite a bit. > > To resolve these pain points, here is how I would like to proceed. I > would like to copy the AHC async-http-client-mina2 code as is into the > AsyncWeb client repository. Because AHC and AsyncWeb client use > different package names, there shouldn't be any conflicts doing this. > Once that is done, we can look at removing the AHC code that > reimplements functionality available in MINA. As long as all the tests > are passing, we should be fine and if there are gaps in testing, we > should fill those. > > Once that is done, we can look at refactoring the AHC code base to use > the AsyncWeb codec while at the same time, make sure that the AsyncWeb > codec isn't missing any functionality that is implemented in AHC. > > I think at this point, we can rename the AHC packages and move it over > top the current AsyncWeb client. Am I missing anything in AsyncWeb > client that needs to merged into AHC? It's only four classes and I > didn't see anything in there that isn't available in AHC. > > Before going ahead and doing this, I wanted to know what everyone else > thinks of this plan. Does anyone else have a different idea as to how > best to undertake this merge? Am I missing anything? > > -Mike > > > > Sangjin Lee wrote: > > Yeah I believe so (as far as I can tell). It was more or less a > > straightforward porting, so there might be interesting and subtle > behavior > > changes we may need to look at. But it should be a good solid baseline. > > Thanks, > > Sangjin > > > > > > On Feb 4, 2008 2:50 PM, Mike Heath <[EMAIL PROTECTED]> wrote: > > > >> Rick McGuire wrote: > >>> I had some time this morning, and decided to take a look at this. It > >>> was fairly straightforward merging the changes back in to the 2.0 > >>> sandbox branch. > >>> There's a bit of a problem going on here with the jsps used for the > >>> tests. In the 1.1.5-based version, there was no eol-style property > set > >>> for the jsps. This caused the strings that were returned by the tests > >>> to use \n for line terminators, which the unit tests expected to find > in > >>> the message responses. In the 2.0 version, the eol-style is set to > >>> native, which causes the unit tests to fail when run on a Windows > >>> system. I was able to hack these up so they're now running cleanly, > but > >>> I'm not terribly confident these won't end up breaking again in the > >>> future. I suspect a less encoding-specific approach is going to be > >>> needed for validating the responses should be used. > >>> > >>> Rick > >> Rick, > >> > >> Does > >> > http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/ > >> contain all the bug fixes and latest features of AsyncHttpClient? Can > >> we use this to merge the changes over to the client under MINA? > >> > >> -Mike > >> > >> <snip> > >> > > > >
