I think Jeff started working on some of it over at MINA btw. Excuse the cross post.
Alex On Jan 9, 2008 4:10 PM, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > If it is better and easier than http-client are they interested in > it? Seems like a logical fit. That said, I think Genender boy wanted > to melt some metal when he started this work. If it remains without a > home I'd put it in components and let folks pick it up if they are > interested. > > On Jan 9, 2008, at 9:55 AM, Kevan Miller wrote: > > > > > On Jan 8, 2008, at 9:59 AM, Donald Woods wrote: > > > >> #3 is okay with me. Was just thinking that #2 (plugin) would allow > >> us to expose it on our plugin website and allow other users to just > >> place a dependency on it in their plugins.... > > > > Oops. Got distracted and forgot to reply... > > > > I was thinking that AHC functionality could be released under > > components (and thus easier to consume by other projects). We can > > then create a plugin which includes this component. So, really a > > combination of 2 and 3. > > > > --kevan > > > > > >> > >> > >> -Donald > >> > >> Kevan Miller wrote: > >>> On Jan 5, 2008, at 2:45 PM, Donald Woods wrote: > >>>> There has been a lot of ongoing work by Jeff, Prasad, Rick, > >>>> Sangjin and others on the AsyncHttpClient (aka. AHC) code in the > >>>> sandbox and I'd like to start the discussion on moving it from > >>>> sandbox into trunk. > >>>> > >>>> There are a couple options as to where it could reside - > >>>> 1) under server/trunk/applications > >>>> 2) under server/trunk/plugins > >>>> 3) under geronimo/components/ > >>>> > >>>> What are everyone's thoughts? I'd like to get this into our 2.1 > >>>> release and possibly into the 2.0.x branch if time allows. > >>> Personally, I don't think it should go into server/trunk. > >>> There's a 4'th option -- create a subproject (e.g. geronimo/ahc). > >>> The only real difference, between this and 3) is web site, jira, > >>> etc. > >>> At the moment, I'm leaning towards 3) -- geronimo/components/ahc > >>> (or some more descriptive name), but could probably be swayed... > >>> --kevan > > > > > >
