[AsyncHttpClient] On bringing the code bases and communities together

[Alex Karasulu <ak...@apache.org>]

Hi,

Please excuse the cross post but it's quite necessary. Furthermore people
should not feel like they cannot cross post responses so please feel free.

It looks like the two versions of the http client based on MINA are starting
to diverge.  I've noticed the other day that some of the fixes for bugs
already solved by one group are being re-implement all over again over again
by another.  It's a shame to have that happen so perhaps we can take some
concrete steps to prevent this divergence from progressing.

As a first step I've cleaned up and restructured the Asyncweb code base and
posted this email here on the new directory structure in Subversion:

  *http://tinyurl.com/ypmbd3

*So I'm sending out this cross post in the hopes of bringing the two groups
together as one unified community which apparently has the same goal in
mind: a fast low-resource consuming asynchronous http client.  What ever it
takes, I'm sure the MINA PMC is more than willing to accommodate.  If you
have trusted committers already working on this in the Geronimo community
there is no reason why we cannot trust them to continue working on it here
at MINA's Asyncweb project.  Let's open up discussions on this.

Specifically I ask the Geronimo committers working on AHC to let us know
what we can do to take concrete next steps.

Thanks,
Alex

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender <jg...@apache.org>]

Actually I already made a Mina 2.x version that is in the G sandbox ;-)

Jeff

Kevan Miller wrote:
> 
> On Jan 29, 2008, at 7:28 PM, Mike Heath wrote:
> 
>> Alex Karasulu wrote:
>>> Hi,
>>>
>>> Please excuse the cross post but it's quite necessary. Furthermore 
>>> people
>>> should not feel like they cannot cross post responses so please feel 
>>> free.
>>>
>>> It looks like the two versions of the http client based on MINA are 
>>> starting
>>> to diverge.  I've noticed the other day that some of the fixes for bugs
>>> already solved by one group are being re-implement all over again 
>>> over again
>>> by another.  It's a shame to have that happen so perhaps we can take 
>>> some
>>> concrete steps to prevent this divergence from progressing.
>>>
>>> As a first step I've cleaned up and restructured the Asyncweb code 
>>> base and
>>> posted this email here on the new directory structure in Subversion:
>>>
>>>  *http://tinyurl.com/ypmbd3
>>>
>>> *So I'm sending out this cross post in the hopes of bringing the two 
>>> groups
>>> together as one unified community which apparently has the same goal in
>>> mind: a fast low-resource consuming asynchronous http client.  What 
>>> ever it
>>> takes, I'm sure the MINA PMC is more than willing to accommodate.  If 
>>> you
>>> have trusted committers already working on this in the Geronimo 
>>> community
>>> there is no reason why we cannot trust them to continue working on it 
>>> here
>>> at MINA's Asyncweb project.  Let's open up discussions on this.
>>
>> I totally agree with Alex on this.  It looks there are fixes in the G
>> branch that haven't made it to the MINA branch.  How can bridge the gap
>> in communication as well as the gap in bug fixing?
>>
>> My opinion is that we need to stop all work on the G sandbox branch and
>> move all work over to MINA.  Is there anything impeding that? ...besides
>> a lot of work merging the changes...
> 
> Thanks Alex and Mike.
> 
> So, as we discussed the last time, the community members that have been 
> active in this area are Jeff Genender, Sangjin Lee, and Rick McGuire. 
> You already know Jeff. Have you reached out to Sangjin and Rick? I'd 
> urge them both to become involved in the Mina community, as their time 
> and interest permit.
> 
> Personally, I'm certainly in favor of seeing a united effort in creating 
> an async http client. Mina would seem to be a natural home for this 
> support (since Mina 2.x is moving up the stack and implementing 
> protocols). I think our community would be quite happy to receive this 
> capability by consumng Mina technology. Given the current state of our 
> two projects, I think it's somewhat doubtful that the Geronimo project 
> will end up releasing the AsyncHTTPClient code in our sandbox.
> 
> I can understand, however, if Rick and Sangjin see value in the current 
> codebase -- being based on a released version of Mina (1.1.2)  and 
> perhaps at a different point in terms of stability and function. I 
> suspect that this might be part of the reason why they haven't become 
> involved in the 2.x development work occurring at Mina.
> 
> So, one possible solution that occurs to me is to transfer the current 
> 1.1.x code in Geronimo sandbox to the Mina project. This might allow 
> Rick and Sangjin to complete their work on the current codebase and also 
> ease their transition towards merging code and fixes into the Mina 2.x 
> codebase. Alternatively, we can leave the code in Geronimo sandbox while 
> Sangjin and Rick transition their focus to the Mina 2.x support.
> 
> Will leave it to the Mina project, Rick, and Sangjin to say what makes 
> the most sense.
> 
> --kevan
> 
> 
> 
> 
> 
> 
> 
> 
> 

Re: [AsyncHttpClient] On bringing the code bases and communities together

[jv...@archean.fr]

sorry for double post,I'm out of my office and using webmail which is
really bugged :(

Sorry for the inconvenience,

Julien

Re: [AsyncHttpClient] On bringing the code bases and communities together

[jv...@archean.fr]

Hi
> Just so I understand...
> What is the direction we're taking?  Just for the terminology sake, I'll
> call these versions
>
> - g-ahc-v1: Geronimo AHC based on Mina 1.1 (the one that Rick and I were
> working on).
> - g-ahc-v2: Geronimo AHC based on Mina trunk
> - mina-ahc: Mina AHC that was refactored into asyncweb
>
> Are we migrating changes from g-ahc-v1 to g-ahc-v2 first and will try to
> migrate them again from g-ahc-v2 to mina-ahc?

I think it's a good way, the first thing is probably to freeze the
g-ahc-v1 for avoid more porting.
The main problem for migrate to mina-ahc is the new Asynweb state based
codec. You think a lot of feature are missing from mina http codec from
the g-ahc one ?

Julien (not sure to be clear)
>
> Thanks,
> Sangjin
>
>
> On Jan 30, 2008 6:36 PM, Alex Karasulu <ak...@apache.org> wrote:
>
>> On Jan 30, 2008 1:49 PM, Jeff Genender <jg...@apache.org> wrote:
>>
>> > Being that its in the sandbox...anything goes. ;-)
>> >
>> > However...with that said...lets see what pans out here at Mina.  I
>> would
>> > certainly consider the delta now before we get 3 diverse versions ;-)
>> >
>> > Yes the preferred version is Mina 2.x.
>> >
>> >
>> Indeed! We might want to first make sure the two Geronimo forks are
>> merged
>> and using MINA 2.0.  Meaning all the features and fixes in the one based
>> on
>> MINA 1.1.x are put into the one based on MINA 2.0-M1.
>>
>> That might bring the consolidated Geronimo fork closer to the MINA
>> version
>> in Asyncweb trunk.  Then we can focus on how to merge these two
>> together?
>>
>> Alex
>>
>

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Sangjin Lee <sj...@gmail.com>]

Thanks Rick!  This was fast.  I'll also take a quick look...

Regards,
Sangjin

On Feb 1, 2008 11:17 AM, Jeff Genender <jg...@apache.org> wrote:

> Or you can use Linux or Mac ;-)
>
> j/k!
>
> Thanks for looking into that Rick.
>
> Jeff
>
> 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
> >
> >
> > Jeff Genender wrote:
> >> Yes.. I think that is the best course of action.  I think they are
> >> pretty similar since I created the mina 2 version in late December.  I
> >> think the delta is rather small.
> >>
> >> Jeff
> >>
> >> On Jan 31, 2008, at 1:34 PM, "Sangjin Lee" <sj...@gmail.com> wrote:
> >>
> >>> Just so I understand...
> >>> What is the direction we're taking?  Just for the terminology sake,
> I'll
> >>> call these versions
> >>>
> >>> - g-ahc-v1: Geronimo AHC based on Mina 1.1 (the one that Rick and I
> were
> >>> working on)
> >>> - g-ahc-v2: Geronimo AHC based on Mina trunk
> >>> - mina-ahc: Mina AHC that was refactored into asyncweb
> >>>
> >>> Are we migrating changes from g-ahc-v1 to g-ahc-v2 first and will try
> to
> >>> migrate them again from g-ahc-v2 to mina-ahc?
> >>>
> >>> Thanks,
> >>> Sangjin
> >>>
> >>>
> >>> On Jan 30, 2008 6:36 PM, Alex Karasulu <ak...@apache.org> wrote:
> >>>
> >>>> On Jan 30, 2008 1:49 PM, Jeff Genender <jg...@apache.org> wrote:
> >>>>
> >>>>> Being that its in the sandbox...anything goes. ;-)
> >>>>>
> >>>>> However...with that said...lets see what pans out here at Mina.  I
> >>>>> would
> >>>>> certainly consider the delta now before we get 3 diverse versions
> ;-)
> >>>>>
> >>>>> Yes the preferred version is Mina 2.x.
> >>>>>
> >>>>>
> >>>> Indeed! We might want to first make sure the two Geronimo forks are
> >>>> merged
> >>>> and using MINA 2.0.  Meaning all the features and fixes in the one
> >>>> based
> >>>> on
> >>>> MINA 1.1.x are put into the one based on MINA 2.0-M1.
> >>>>
> >>>> That might bring the consolidated Geronimo fork closer to the MINA
> >>>> version
> >>>> in Asyncweb trunk.  Then we can focus on how to merge these two
> >>>> together?
> >>>>
> >>>> Alex
> >>>>
> >>
>

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Alex Karasulu <ak...@apache.org>]

Excellent thanks.

Alex

On Feb 5, 2008 9:50 AM, Maarten Bosteels <mb...@gmail.com> wrote:

> On Feb 5, 2008 10:07 AM, Alex Karasulu <ak...@apache.org> wrote:
>
> > Thanks Julien this is cool.
> >
> > Trustin why isn't any of this code documented?  Would be nice if users
> can
> > see what this is about ... might make people use it more.
>
>
>
> see https://issues.apache.org/jira/browse/DIRMINA-92#action_12488311
> for more details
>
> Maarten
>
>
> >
> > Alex
> >
> > On Feb 5, 2008 3:07 AM, Julien Vermillard <jv...@archean.fr>
> wrote:
> >
> > > On Mon, 04 Feb 2008 22:02:19 -0700
> > > Jeff Genender <jg...@apache.org> wrote:
> > >
> > > >
> > > >
> > > > Mike Heath wrote:
> > > > > To clarify, my understanding of pipelining is that it is sending
> > > > > multiple requests and then waiting for the corresponding
> responses.
> > > > > This is more than HTTP keep alive which would also allow using a
> > > > > single connection for multiple requests but doesn't necessarily
> > > > > involve the batching of pipelining.
> > > >
> > > > I understand it slightly different..that you can send multiple
> > > > requests through the same socket.  The difference between what you
> > > > said and what I said is I think pipelining does not have stacked
> > > > waiting.
> > > >
> > > > >
> > > > >> But if you are saying its possible, then great!
> > > > >
> > > > > What I'm saying is that in the AHC code at
> > > > >
> > >
> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2
> > ,
> > > > > the HttpIoHandler.TimeoutTask is unaware of which request has been
> > > > > sent. It only knows which IoSession is being used (that's the only
> > > > > field in the TimeoutTask).  So essentially the timeout logic as it
> > > > > is implemented in AHC is no different than using the MINA idle
> > > > > logic.
> > > > >
> > > > > Does the AHC client currently support pipelining?  If I issue two
> > > > > pipelined requests, and the first one times out causing the
> session
> > > > > to close.  How does the future of the second request get notified
> > > > > of the timeout?  I only see code for working with CURRENT_REQUEST
> > > > > (from the IoSession attributes).  I don't see any code for dealing
> > > > > with pending requests.
> > > > >
> > > >
> > > > You are right....no AHC does not support pipelining but we were
> coding
> > > > it to go in that direction so we could.  We knew that it would be a
> > > > lot more complex to implement, but wanted to sow the seeds of the
> > > > code to handle it when we did.
> > > >
> > > > OTOH, I must admit I implemented the ScheduledExecutor based on the
> > > > FAQ and a few IRC discussions ;-)  but if sessionIdle will work,
> then
> > > > that would be the way to go.
> > > >
> > > > > -Mike
> > > > >
> > > > > BTW - Thanks for the discussion, Jeff.  It's really helped me to
> go
> > > > > back and look deeper in the AHC code.
> > > >
> > > > Thank you...and thanks for taking an interest...this is great ;-)
> > > >
> > > > >
> > > > > -Mike
> > >
> > > Hi,
> > >
> > > Just by the way, if you want to monitor a request/response behaviour
> you
> > > got the reqres filter :
> > >
> > >
> >
> http://svn.apache.org/viewvc/mina/trunk/core/src/main/java/org/apache/mina/filter/reqres/
> > >
> > > Julien
> > >
> >
>

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Maarten Bosteels <mb...@gmail.com>]

On Feb 5, 2008 10:07 AM, Alex Karasulu <ak...@apache.org> wrote:

> Thanks Julien this is cool.
>
> Trustin why isn't any of this code documented?  Would be nice if users can
> see what this is about ... might make people use it more.



see https://issues.apache.org/jira/browse/DIRMINA-92#action_12488311
for more details

Maarten


>
> Alex
>
> On Feb 5, 2008 3:07 AM, Julien Vermillard <jv...@archean.fr> wrote:
>
> > On Mon, 04 Feb 2008 22:02:19 -0700
> > Jeff Genender <jg...@apache.org> wrote:
> >
> > >
> > >
> > > Mike Heath wrote:
> > > > To clarify, my understanding of pipelining is that it is sending
> > > > multiple requests and then waiting for the corresponding responses.
> > > > This is more than HTTP keep alive which would also allow using a
> > > > single connection for multiple requests but doesn't necessarily
> > > > involve the batching of pipelining.
> > >
> > > I understand it slightly different..that you can send multiple
> > > requests through the same socket.  The difference between what you
> > > said and what I said is I think pipelining does not have stacked
> > > waiting.
> > >
> > > >
> > > >> But if you are saying its possible, then great!
> > > >
> > > > What I'm saying is that in the AHC code at
> > > >
> > http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2
> ,
> > > > the HttpIoHandler.TimeoutTask is unaware of which request has been
> > > > sent. It only knows which IoSession is being used (that's the only
> > > > field in the TimeoutTask).  So essentially the timeout logic as it
> > > > is implemented in AHC is no different than using the MINA idle
> > > > logic.
> > > >
> > > > Does the AHC client currently support pipelining?  If I issue two
> > > > pipelined requests, and the first one times out causing the session
> > > > to close.  How does the future of the second request get notified
> > > > of the timeout?  I only see code for working with CURRENT_REQUEST
> > > > (from the IoSession attributes).  I don't see any code for dealing
> > > > with pending requests.
> > > >
> > >
> > > You are right....no AHC does not support pipelining but we were coding
> > > it to go in that direction so we could.  We knew that it would be a
> > > lot more complex to implement, but wanted to sow the seeds of the
> > > code to handle it when we did.
> > >
> > > OTOH, I must admit I implemented the ScheduledExecutor based on the
> > > FAQ and a few IRC discussions ;-)  but if sessionIdle will work, then
> > > that would be the way to go.
> > >
> > > > -Mike
> > > >
> > > > BTW - Thanks for the discussion, Jeff.  It's really helped me to go
> > > > back and look deeper in the AHC code.
> > >
> > > Thank you...and thanks for taking an interest...this is great ;-)
> > >
> > > >
> > > > -Mike
> >
> > Hi,
> >
> > Just by the way, if you want to monitor a request/response behaviour you
> > got the reqres filter :
> >
> >
> http://svn.apache.org/viewvc/mina/trunk/core/src/main/java/org/apache/mina/filter/reqres/
> >
> > Julien
> >
>

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Alex Karasulu <ak...@apache.org>]

Thanks Julien this is cool.

Trustin why isn't any of this code documented?  Would be nice if users can
see what this is about ... might make people use it more.

Alex

On Feb 5, 2008 3:07 AM, Julien Vermillard <jv...@archean.fr> wrote:

> On Mon, 04 Feb 2008 22:02:19 -0700
> Jeff Genender <jg...@apache.org> wrote:
>
> >
> >
> > Mike Heath wrote:
> > > To clarify, my understanding of pipelining is that it is sending
> > > multiple requests and then waiting for the corresponding responses.
> > > This is more than HTTP keep alive which would also allow using a
> > > single connection for multiple requests but doesn't necessarily
> > > involve the batching of pipelining.
> >
> > I understand it slightly different..that you can send multiple
> > requests through the same socket.  The difference between what you
> > said and what I said is I think pipelining does not have stacked
> > waiting.
> >
> > >
> > >> But if you are saying its possible, then great!
> > >
> > > What I'm saying is that in the AHC code at
> > >
> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2,
> > > the HttpIoHandler.TimeoutTask is unaware of which request has been
> > > sent. It only knows which IoSession is being used (that's the only
> > > field in the TimeoutTask).  So essentially the timeout logic as it
> > > is implemented in AHC is no different than using the MINA idle
> > > logic.
> > >
> > > Does the AHC client currently support pipelining?  If I issue two
> > > pipelined requests, and the first one times out causing the session
> > > to close.  How does the future of the second request get notified
> > > of the timeout?  I only see code for working with CURRENT_REQUEST
> > > (from the IoSession attributes).  I don't see any code for dealing
> > > with pending requests.
> > >
> >
> > You are right....no AHC does not support pipelining but we were coding
> > it to go in that direction so we could.  We knew that it would be a
> > lot more complex to implement, but wanted to sow the seeds of the
> > code to handle it when we did.
> >
> > OTOH, I must admit I implemented the ScheduledExecutor based on the
> > FAQ and a few IRC discussions ;-)  but if sessionIdle will work, then
> > that would be the way to go.
> >
> > > -Mike
> > >
> > > BTW - Thanks for the discussion, Jeff.  It's really helped me to go
> > > back and look deeper in the AHC code.
> >
> > Thank you...and thanks for taking an interest...this is great ;-)
> >
> > >
> > > -Mike
>
> Hi,
>
> Just by the way, if you want to monitor a request/response behaviour you
> got the reqres filter :
>
> http://svn.apache.org/viewvc/mina/trunk/core/src/main/java/org/apache/mina/filter/reqres/
>
> Julien
>

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Rick McGuire <ri...@gmail.com>]

This sounds like an excellent approach to merging the efforts.

Rick


Mike Heath 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 <mh...@apache.org> 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>
>>>
>>>       
>
>
>   

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Sangjin Lee <sj...@gmail.com>]

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 <mh...@apache.org> 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 <mh...@apache.org> 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>
> >>
> >
>
>

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender <jg...@apache.org>]

Wow...this is awesome...I could have used this because this is
essentially the same mechanism I wrote in AHC ;-)

Yeah...this should be documented in the FAQ somewhere as this would come
in handy.

Jeff

Julien Vermillard wrote:
> Hi,
> 
> Just by the way, if you want to monitor a request/response behaviour you
> got the reqres filter :
> http://svn.apache.org/viewvc/mina/trunk/core/src/main/java/org/apache/mina/filter/reqres/
> 
> Julien

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Julien Vermillard <jv...@archean.fr>]

On Mon, 04 Feb 2008 22:02:19 -0700
Jeff Genender <jg...@apache.org> wrote:

> 
> 
> Mike Heath wrote:
> > To clarify, my understanding of pipelining is that it is sending
> > multiple requests and then waiting for the corresponding responses.
> > This is more than HTTP keep alive which would also allow using a
> > single connection for multiple requests but doesn't necessarily
> > involve the batching of pipelining.
> 
> I understand it slightly different..that you can send multiple
> requests through the same socket.  The difference between what you
> said and what I said is I think pipelining does not have stacked
> waiting.
> 
> > 
> >> But if you are saying its possible, then great!
> > 
> > What I'm saying is that in the AHC code at
> > http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2,
> > the HttpIoHandler.TimeoutTask is unaware of which request has been
> > sent. It only knows which IoSession is being used (that's the only
> > field in the TimeoutTask).  So essentially the timeout logic as it
> > is implemented in AHC is no different than using the MINA idle
> > logic.
> > 
> > Does the AHC client currently support pipelining?  If I issue two
> > pipelined requests, and the first one times out causing the session
> > to close.  How does the future of the second request get notified
> > of the timeout?  I only see code for working with CURRENT_REQUEST
> > (from the IoSession attributes).  I don't see any code for dealing
> > with pending requests.
> > 
> 
> You are right....no AHC does not support pipelining but we were coding
> it to go in that direction so we could.  We knew that it would be a
> lot more complex to implement, but wanted to sow the seeds of the
> code to handle it when we did.
> 
> OTOH, I must admit I implemented the ScheduledExecutor based on the
> FAQ and a few IRC discussions ;-)  but if sessionIdle will work, then
> that would be the way to go.
> 
> > -Mike
> > 
> > BTW - Thanks for the discussion, Jeff.  It's really helped me to go
> > back and look deeper in the AHC code.
> 
> Thank you...and thanks for taking an interest...this is great ;-)
> 
> > 
> > -Mike

Hi,

Just by the way, if you want to monitor a request/response behaviour you
got the reqres filter :
http://svn.apache.org/viewvc/mina/trunk/core/src/main/java/org/apache/mina/filter/reqres/

Julien

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender <jg...@apache.org>]

Mike Heath wrote:
> To clarify, my understanding of pipelining is that it is sending
> multiple requests and then waiting for the corresponding responses.
> This is more than HTTP keep alive which would also allow using a single
> connection for multiple requests but doesn't necessarily involve the
> batching of pipelining.

I understand it slightly different..that you can send multiple requests
through the same socket.  The difference between what you said and what
I said is I think pipelining does not have stacked waiting.

> 
>> But if you are saying its possible, then great!
> 
> What I'm saying is that in the AHC code at
> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2,
> the HttpIoHandler.TimeoutTask is unaware of which request has been sent.
>  It only knows which IoSession is being used (that's the only field in
> the TimeoutTask).  So essentially the timeout logic as it is implemented
> in AHC is no different than using the MINA idle logic.
> 
> Does the AHC client currently support pipelining?  If I issue two
> pipelined requests, and the first one times out causing the session to
> close.  How does the future of the second request get notified of the
> timeout?  I only see code for working with CURRENT_REQUEST (from the
> IoSession attributes).  I don't see any code for dealing with pending
> requests.
> 

You are right....no AHC does not support pipelining but we were coding
it to go in that direction so we could.  We knew that it would be a lot
more complex to implement, but wanted to sow the seeds of the code to
handle it when we did.

OTOH, I must admit I implemented the ScheduledExecutor based on the FAQ
and a few IRC discussions ;-)  but if sessionIdle will work, then that
would be the way to go.

> -Mike
> 
> BTW - Thanks for the discussion, Jeff.  It's really helped me to go back
> and look deeper in the AHC code.

Thank you...and thanks for taking an interest...this is great ;-)

> 
> -Mike

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Mike Heath <mh...@apache.org>]

Jeff Genender wrote:
> 
> 
> Mike Heath wrote:
>> What the FAQ is saying is that the idle event wont tell you which
>> request message was issued when the timeout occured.  So using an idle
>> read to detect an unresponsive connection is perfectly legitimate.
>>
>> I don't see why using idle wouldn't work for pipelining.  If the session
>> times out, it gets closed which would cause any pending requests to fail
>> anyway.
>>
>> I may just be presumptuous.  Am I missing something?
>>
> 
> This is pipelining...using a single connection for reuse for multiple
> requests, which tells me that a sessionIdle would probably not work.

To clarify, my understanding of pipelining is that it is sending
multiple requests and then waiting for the corresponding responses.
This is more than HTTP keep alive which would also allow using a single
connection for multiple requests but doesn't necessarily involve the
batching of pipelining.

> But if you are saying its possible, then great!

What I'm saying is that in the AHC code at
http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2,
the HttpIoHandler.TimeoutTask is unaware of which request has been sent.
 It only knows which IoSession is being used (that's the only field in
the TimeoutTask).  So essentially the timeout logic as it is implemented
in AHC is no different than using the MINA idle logic.

Does the AHC client currently support pipelining?  If I issue two
pipelined requests, and the first one times out causing the session to
close.  How does the future of the second request get notified of the
timeout?  I only see code for working with CURRENT_REQUEST (from the
IoSession attributes).  I don't see any code for dealing with pending
requests.

-Mike

BTW - Thanks for the discussion, Jeff.  It's really helped me to go back
and look deeper in the AHC code.

-Mike

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender <jg...@apache.org>]

Mike Heath wrote:
> What the FAQ is saying is that the idle event wont tell you which
> request message was issued when the timeout occured.  So using an idle
> read to detect an unresponsive connection is perfectly legitimate.
> 
> I don't see why using idle wouldn't work for pipelining.  If the session
> times out, it gets closed which would cause any pending requests to fail
> anyway.
> 
> I may just be presumptuous.  Am I missing something?
> 

This is pipelining...using a single connection for reuse for multiple 
requests, which tells me that a sessionIdle would probably not work.

But if you are saying its possible, then great!

Jeff

> -Mike

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Mike Heath <mh...@apache.org>]

Jeff Genender wrote:
> 
> 
> Mike Heath wrote:
>> Jeff Genender wrote:
>>
>> <snip>
>>> I think this timeout is a different timeout in implementation...that is
>>> unless this was added to 2.0, then duplication may be correct.  Its a
>>> response timeout, not socket timeout...I think thats different.
>>
>> MINA has support for triggering events for read idle, write idle, or
>> both.  See IoSession.setIdleTime(IdleStatus, int) in MINA 1.x and
>> IoSession.getConfig().setIdleTime(IdleStatus,int) in MINA 2.  The idle
>> events get handled by IoHandler.sessionIdle(IoSession, IdleStatus) in
>> both versions.
> 
> Will idle work here?  The Mina FAQ states that sessionIdle cannot be
> used in a request-response timeout:
> 
> http://tinyurl.com/25gnja
> 
> Also, with pipelining, can idle time even be used?

What the FAQ is saying is that the idle event wont tell you which
request message was issued when the timeout occured.  So using an idle
read to detect an unresponsive connection is perfectly legitimate.

I don't see why using idle wouldn't work for pipelining.  If the session
times out, it gets closed which would cause any pending requests to fail
anyway.

I may just be presumptuous.  Am I missing something?

-Mike

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender <jg...@apache.org>]

Mike Heath wrote:
> Jeff Genender wrote:
> 
> <snip>
>> I think this timeout is a different timeout in implementation...that is
>> unless this was added to 2.0, then duplication may be correct.  Its a
>> response timeout, not socket timeout...I think thats different.
> 
> MINA has support for triggering events for read idle, write idle, or
> both.  See IoSession.setIdleTime(IdleStatus, int) in MINA 1.x and
> IoSession.getConfig().setIdleTime(IdleStatus,int) in MINA 2.  The idle
> events get handled by IoHandler.sessionIdle(IoSession, IdleStatus) in
> both versions.

Will idle work here?  The Mina FAQ states that sessionIdle cannot be 
used in a request-response timeout:

http://tinyurl.com/25gnja

Also, with pipelining, can idle time even be used?

Jeff

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Mike Heath <mh...@apache.org>]

Jeff Genender wrote:

<snip>
> I think this timeout is a different timeout in implementation...that is
> unless this was added to 2.0, then duplication may be correct.  Its a
> response timeout, not socket timeout...I think thats different.

MINA has support for triggering events for read idle, write idle, or
both.  See IoSession.setIdleTime(IdleStatus, int) in MINA 1.x and
IoSession.getConfig().setIdleTime(IdleStatus,int) in MINA 2.  The idle
events get handled by IoHandler.sessionIdle(IoSession, IdleStatus) in
both versions.

<snip>

> I like the plan...seems like a good way to go.


Thanks for the feedback.  I'll get started on this tomorrow.

-Mike

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender <jg...@apache.org>]

Mike Heath 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)

I think this timeout is a different timeout in implementation...that is
unless this was added to 2.0, then duplication may be correct.  Its a
response timeout, not socket timeout...I think thats different.

>  - 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?
> 

I like the plan...seems like a good way to go.


> -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 <mh...@apache.org> 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>
>>>

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Mike Heath <mh...@apache.org>]

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 <mh...@apache.org> 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>
>>
> 

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Sangjin Lee <sj...@gmail.com>]

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 <mh...@apache.org> 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>
>

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Mike Heath <mh...@apache.org>]

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>

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender <jg...@apache.org>]

Or you can use Linux or Mac ;-)

j/k!

Thanks for looking into that Rick.

Jeff

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
> 
> 
> Jeff Genender wrote:
>> Yes.. I think that is the best course of action.  I think they are
>> pretty similar since I created the mina 2 version in late December.  I
>> think the delta is rather small.
>>
>> Jeff
>>
>> On Jan 31, 2008, at 1:34 PM, "Sangjin Lee" <sj...@gmail.com> wrote:
>>
>>> Just so I understand...
>>> What is the direction we're taking?  Just for the terminology sake, I'll
>>> call these versions
>>>
>>> - g-ahc-v1: Geronimo AHC based on Mina 1.1 (the one that Rick and I were
>>> working on)
>>> - g-ahc-v2: Geronimo AHC based on Mina trunk
>>> - mina-ahc: Mina AHC that was refactored into asyncweb
>>>
>>> Are we migrating changes from g-ahc-v1 to g-ahc-v2 first and will try to
>>> migrate them again from g-ahc-v2 to mina-ahc?
>>>
>>> Thanks,
>>> Sangjin
>>>
>>>
>>> On Jan 30, 2008 6:36 PM, Alex Karasulu <ak...@apache.org> wrote:
>>>
>>>> On Jan 30, 2008 1:49 PM, Jeff Genender <jg...@apache.org> wrote:
>>>>
>>>>> Being that its in the sandbox...anything goes. ;-)
>>>>>
>>>>> However...with that said...lets see what pans out here at Mina.  I
>>>>> would
>>>>> certainly consider the delta now before we get 3 diverse versions ;-)
>>>>>
>>>>> Yes the preferred version is Mina 2.x.
>>>>>
>>>>>
>>>> Indeed! We might want to first make sure the two Geronimo forks are
>>>> merged
>>>> and using MINA 2.0.  Meaning all the features and fixes in the one
>>>> based
>>>> on
>>>> MINA 1.1.x are put into the one based on MINA 2.0-M1.
>>>>
>>>> That might bring the consolidated Geronimo fork closer to the MINA
>>>> version
>>>> in Asyncweb trunk.  Then we can focus on how to merge these two
>>>> together?
>>>>
>>>> Alex
>>>>
>>

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Rick McGuire <ri...@gmail.com>]

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


Jeff Genender wrote:
> Yes.. I think that is the best course of action.  I think they are 
> pretty similar since I created the mina 2 version in late December.  I 
> think the delta is rather small.
>
> Jeff
>
> On Jan 31, 2008, at 1:34 PM, "Sangjin Lee" <sj...@gmail.com> wrote:
>
>> Just so I understand...
>> What is the direction we're taking?  Just for the terminology sake, I'll
>> call these versions
>>
>> - g-ahc-v1: Geronimo AHC based on Mina 1.1 (the one that Rick and I were
>> working on)
>> - g-ahc-v2: Geronimo AHC based on Mina trunk
>> - mina-ahc: Mina AHC that was refactored into asyncweb
>>
>> Are we migrating changes from g-ahc-v1 to g-ahc-v2 first and will try to
>> migrate them again from g-ahc-v2 to mina-ahc?
>>
>> Thanks,
>> Sangjin
>>
>>
>> On Jan 30, 2008 6:36 PM, Alex Karasulu <ak...@apache.org> wrote:
>>
>>> On Jan 30, 2008 1:49 PM, Jeff Genender <jg...@apache.org> wrote:
>>>
>>>> Being that its in the sandbox...anything goes. ;-)
>>>>
>>>> However...with that said...lets see what pans out here at Mina.  I 
>>>> would
>>>> certainly consider the delta now before we get 3 diverse versions ;-)
>>>>
>>>> Yes the preferred version is Mina 2.x.
>>>>
>>>>
>>> Indeed! We might want to first make sure the two Geronimo forks are 
>>> merged
>>> and using MINA 2.0.  Meaning all the features and fixes in the one 
>>> based
>>> on
>>> MINA 1.1.x are put into the one based on MINA 2.0-M1.
>>>
>>> That might bring the consolidated Geronimo fork closer to the MINA 
>>> version
>>> in Asyncweb trunk.  Then we can focus on how to merge these two 
>>> together?
>>>
>>> Alex
>>>
>

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender <jg...@savoirtech.com>]

Yes.. I think that is the best course of action.  I think they are  
pretty similar since I created the mina 2 version in late December.  I  
think the delta is rather small.

Jeff

On Jan 31, 2008, at 1:34 PM, "Sangjin Lee" <sj...@gmail.com> wrote:

> Just so I understand...
> What is the direction we're taking?  Just for the terminology sake,  
> I'll
> call these versions
>
> - g-ahc-v1: Geronimo AHC based on Mina 1.1 (the one that Rick and I  
> were
> working on)
> - g-ahc-v2: Geronimo AHC based on Mina trunk
> - mina-ahc: Mina AHC that was refactored into asyncweb
>
> Are we migrating changes from g-ahc-v1 to g-ahc-v2 first and will  
> try to
> migrate them again from g-ahc-v2 to mina-ahc?
>
> Thanks,
> Sangjin
>
>
> On Jan 30, 2008 6:36 PM, Alex Karasulu <ak...@apache.org> wrote:
>
>> On Jan 30, 2008 1:49 PM, Jeff Genender <jg...@apache.org> wrote:
>>
>>> Being that its in the sandbox...anything goes. ;-)
>>>
>>> However...with that said...lets see what pans out here at Mina.  I  
>>> would
>>> certainly consider the delta now before we get 3 diverse  
>>> versions ;-)
>>>
>>> Yes the preferred version is Mina 2.x.
>>>
>>>
>> Indeed! We might want to first make sure the two Geronimo forks are  
>> merged
>> and using MINA 2.0.  Meaning all the features and fixes in the one  
>> based
>> on
>> MINA 1.1.x are put into the one based on MINA 2.0-M1.
>>
>> That might bring the consolidated Geronimo fork closer to the MINA  
>> version
>> in Asyncweb trunk.  Then we can focus on how to merge these two  
>> together?
>>
>> Alex
>>

Re: [AsyncHttpClient] On bringing the code bases and communities together

[jv...@archean.fr]

Hi,
> Just so I understand...
> What is the direction we're taking?  Just for the terminology sake, I'll
> call these versions
>
> - g-ahc-v1: Geronimo AHC based on Mina 1.1 (the one that Rick and I were
> working on)
> - g-ahc-v2: Geronimo AHC based on Mina trunk
> - mina-ahc: Mina AHC that was refactored into asyncweb
>
> Are we migrating changes from g-ahc-v1 to g-ahc-v2 first and will try to
> migrate them again from g-ahc-v2 to mina-ahc?
>

I think it's a good idea. The first thing to do is to freeze the g-ahc-v1
to avoid endless porting between the two branches.

The main problem for the migration back to Asyncweb is the codec, it was
modified a lot ?

Julien

> Thanks,
> Sangjin
>
>
> On Jan 30, 2008 6:36 PM, Alex Karasulu <ak...@apache.org> wrote:
>
>> On Jan 30, 2008 1:49 PM, Jeff Genender <jg...@apache.org> wrote:
>>
>> > Being that its in the sandbox...anything goes. ;-)
>> >
>> > However...with that said...lets see what pans out here at Mina.  I
>> would
>> > certainly consider the delta now before we get 3 diverse versions ;-)
>> >
>> > Yes the preferred version is Mina 2.x.
>> >
>> >
>> Indeed! We might want to first make sure the two Geronimo forks are
>> merged
>> and using MINA 2.0.  Meaning all the features and fixes in the one based
>> on
>> MINA 1.1.x are put into the one based on MINA 2.0-M1.
>>
>> That might bring the consolidated Geronimo fork closer to the MINA
>> version
>> in Asyncweb trunk.  Then we can focus on how to merge these two
>> together?
>>
>> Alex
>>
>

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Sangjin Lee <sj...@gmail.com>]

Just so I understand...
What is the direction we're taking?  Just for the terminology sake, I'll
call these versions

- g-ahc-v1: Geronimo AHC based on Mina 1.1 (the one that Rick and I were
working on)
- g-ahc-v2: Geronimo AHC based on Mina trunk
- mina-ahc: Mina AHC that was refactored into asyncweb

Are we migrating changes from g-ahc-v1 to g-ahc-v2 first and will try to
migrate them again from g-ahc-v2 to mina-ahc?

Thanks,
Sangjin


On Jan 30, 2008 6:36 PM, Alex Karasulu <ak...@apache.org> wrote:

> On Jan 30, 2008 1:49 PM, Jeff Genender <jg...@apache.org> wrote:
>
> > Being that its in the sandbox...anything goes. ;-)
> >
> > However...with that said...lets see what pans out here at Mina.  I would
> > certainly consider the delta now before we get 3 diverse versions ;-)
> >
> > Yes the preferred version is Mina 2.x.
> >
> >
> Indeed! We might want to first make sure the two Geronimo forks are merged
> and using MINA 2.0.  Meaning all the features and fixes in the one based
> on
> MINA 1.1.x are put into the one based on MINA 2.0-M1.
>
> That might bring the consolidated Geronimo fork closer to the MINA version
> in Asyncweb trunk.  Then we can focus on how to merge these two together?
>
> Alex
>

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Alex Karasulu <ak...@apache.org>]

On Jan 30, 2008 1:49 PM, Jeff Genender <jg...@apache.org> wrote:

> Being that its in the sandbox...anything goes. ;-)
>
> However...with that said...lets see what pans out here at Mina.  I would
> certainly consider the delta now before we get 3 diverse versions ;-)
>
> Yes the preferred version is Mina 2.x.
>
>
Indeed! We might want to first make sure the two Geronimo forks are merged
and using MINA 2.0.  Meaning all the features and fixes in the one based on
MINA 1.1.x are put into the one based on MINA 2.0-M1.

That might bring the consolidated Geronimo fork closer to the MINA version
in Asyncweb trunk.  Then we can focus on how to merge these two together?

Alex

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender <jg...@apache.org>]

Being that its in the sandbox...anything goes. ;-)

However...with that said...lets see what pans out here at Mina.  I would 
certainly consider the delta now before we get 3 diverse versions ;-)

Yes the preferred version is Mina 2.x.

Jeff

Rick McGuire wrote:
> Jeff Genender wrote:
>> Rick,
>>
>> This was the port I did to Mina 2:
>>
>> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/
> Jeff,
> 
> Is that the preferred version?  Since that branch is in the geronimo SVN 
> tree, do you have any objections to me directly porting and applying 
> some of the recent 1.1.5 changes to that version?  Or should I submit 
> patches via Jira (and where should the patches be submitted)?  If that's 
> not the preferred version, then which one is?
> 
> Rick
>>
>> Jeff
>>
>> Rick McGuire wrote:
>>> Alex Karasulu wrote:
>>>> Kevan,
>>>>
>>>> Thanks for taking the time to respond.  More inline ...
>>>>
>>>> On Jan 30, 2008 1:08 AM, Kevan Miller <ke...@gmail.com> wrote:
>>>> ...
>>>>
>>>>  
>>>>> So, as we discussed the last time, the community members that have 
>>>>> been
>>>>> active in this area are Jeff Genender, Sangjin Lee, and Rick 
>>>>> McGuire. You
>>>>> already know Jeff. Have you reached out to Sangjin and Rick?
>>>>> I'd urge them both to become involved in the Mina community, as 
>>>>> their time
>>>>> and interest permit.
>>>>>
>>>>>     
>>>>
>>>> Right very good point.
>>>>
>>>> So Sangjin and Rick are you interested in working on this with the 
>>>> rest of
>>>> the asyncweb crew at MINA?
>>>>   
>>> Yes, I'm definitely interested in helping out.  Right now, I'm having 
>>> a hard time figuring which is the correct Mina 2.0 version.  There 
>>> appear to be at least 3 different versions of an AsyncHttpClient 
>>> floating around (one in the Mina trunk, one in the AsyncWeb tree, one 
>>> in the Geronimo sandbox).  Which is the appropriate one to start 
>>> porting the recent changes to the 1.1.5 version to?
>>>
>>> Rick
>>>
>>>
>>>>
>>>>  
>>>>> I can understand, however, if Rick and Sangjin see value in the 
>>>>> current
>>>>> codebase
>>>>>
>>>>>     
>>>>
>>>> NP that's something to consider and evaluate.  And regardless of the 
>>>> code in
>>>> general we can share knowledge and expertise.  I'm sure experiences 
>>>> will rub
>>>> off and this is the most important part of it.  The code here is small
>>>> compared to the collaborative potential.
>>>>
>>>>
>>>>  
>>>>> So, one possible solution that occurs to me is to transfer the current
>>>>> 1.1.x code in Geronimo sandbox to the Mina project. This might 
>>>>> allow Rick
>>>>> and Sangjin to complete their work on the current codebase and also 
>>>>> ease
>>>>> their transition towards merging code and fixes into the Mina 
>>>>> 2.xcodebase. Alternatively, we can leave the code in Geronimo 
>>>>> sandbox while
>>>>> Sangjin and Rick transition their focus to the Mina 2.x support.
>>>>>
>>>>> Will leave it to the Mina project, Rick, and Sangjin to say what 
>>>>> makes the
>>>>> most sense.
>>>>>
>>>>>     
>>>>
>>>> I think all options are open for us.
>>>>
>>>> Thanks for your help towards fostering greater community.
>>>>
>>>> Alex
>>>>
>>>>   
>>

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Rick McGuire <ri...@gmail.com>]

Jeff Genender wrote:
> Rick,
>
> This was the port I did to Mina 2:
>
> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/
Jeff,

Is that the preferred version?  Since that branch is in the geronimo SVN 
tree, do you have any objections to me directly porting and applying 
some of the recent 1.1.5 changes to that version?  Or should I submit 
patches via Jira (and where should the patches be submitted)?  If that's 
not the preferred version, then which one is?

Rick
>
> Jeff
>
> Rick McGuire wrote:
>> Alex Karasulu wrote:
>>> Kevan,
>>>
>>> Thanks for taking the time to respond.  More inline ...
>>>
>>> On Jan 30, 2008 1:08 AM, Kevan Miller <ke...@gmail.com> wrote:
>>> ...
>>>
>>>  
>>>> So, as we discussed the last time, the community members that have 
>>>> been
>>>> active in this area are Jeff Genender, Sangjin Lee, and Rick 
>>>> McGuire. You
>>>> already know Jeff. Have you reached out to Sangjin and Rick?
>>>> I'd urge them both to become involved in the Mina community, as 
>>>> their time
>>>> and interest permit.
>>>>
>>>>     
>>>
>>> Right very good point.
>>>
>>> So Sangjin and Rick are you interested in working on this with the 
>>> rest of
>>> the asyncweb crew at MINA?
>>>   
>> Yes, I'm definitely interested in helping out.  Right now, I'm having 
>> a hard time figuring which is the correct Mina 2.0 version.  There 
>> appear to be at least 3 different versions of an AsyncHttpClient 
>> floating around (one in the Mina trunk, one in the AsyncWeb tree, one 
>> in the Geronimo sandbox).  Which is the appropriate one to start 
>> porting the recent changes to the 1.1.5 version to?
>>
>> Rick
>>
>>
>>>
>>>  
>>>> I can understand, however, if Rick and Sangjin see value in the 
>>>> current
>>>> codebase
>>>>
>>>>     
>>>
>>> NP that's something to consider and evaluate.  And regardless of the 
>>> code in
>>> general we can share knowledge and expertise.  I'm sure experiences 
>>> will rub
>>> off and this is the most important part of it.  The code here is small
>>> compared to the collaborative potential.
>>>
>>>
>>>  
>>>> So, one possible solution that occurs to me is to transfer the current
>>>> 1.1.x code in Geronimo sandbox to the Mina project. This might 
>>>> allow Rick
>>>> and Sangjin to complete their work on the current codebase and also 
>>>> ease
>>>> their transition towards merging code and fixes into the Mina 
>>>> 2.xcodebase. Alternatively, we can leave the code in Geronimo 
>>>> sandbox while
>>>> Sangjin and Rick transition their focus to the Mina 2.x support.
>>>>
>>>> Will leave it to the Mina project, Rick, and Sangjin to say what 
>>>> makes the
>>>> most sense.
>>>>
>>>>     
>>>
>>> I think all options are open for us.
>>>
>>> Thanks for your help towards fostering greater community.
>>>
>>> Alex
>>>
>>>   
>

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender <jg...@apache.org>]

Rick,

This was the port I did to Mina 2:

http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/

Jeff

Rick McGuire wrote:
> Alex Karasulu wrote:
>> Kevan,
>>
>> Thanks for taking the time to respond.  More inline ...
>>
>> On Jan 30, 2008 1:08 AM, Kevan Miller <ke...@gmail.com> wrote:
>> ...
>>
>>  
>>> So, as we discussed the last time, the community members that have been
>>> active in this area are Jeff Genender, Sangjin Lee, and Rick McGuire. 
>>> You
>>> already know Jeff. Have you reached out to Sangjin and Rick?
>>> I'd urge them both to become involved in the Mina community, as their 
>>> time
>>> and interest permit.
>>>
>>>     
>>
>> Right very good point.
>>
>> So Sangjin and Rick are you interested in working on this with the 
>> rest of
>> the asyncweb crew at MINA?
>>   
> Yes, I'm definitely interested in helping out.  Right now, I'm having a 
> hard time figuring which is the correct Mina 2.0 version.  There appear 
> to be at least 3 different versions of an AsyncHttpClient floating 
> around (one in the Mina trunk, one in the AsyncWeb tree, one in the 
> Geronimo sandbox).  Which is the appropriate one to start porting the 
> recent changes to the 1.1.5 version to?
> 
> Rick
> 
> 
>>
>>  
>>> I can understand, however, if Rick and Sangjin see value in the current
>>> codebase
>>>
>>>     
>>
>> NP that's something to consider and evaluate.  And regardless of the 
>> code in
>> general we can share knowledge and expertise.  I'm sure experiences 
>> will rub
>> off and this is the most important part of it.  The code here is small
>> compared to the collaborative potential.
>>
>>
>>  
>>> So, one possible solution that occurs to me is to transfer the current
>>> 1.1.x code in Geronimo sandbox to the Mina project. This might allow 
>>> Rick
>>> and Sangjin to complete their work on the current codebase and also ease
>>> their transition towards merging code and fixes into the Mina 
>>> 2.xcodebase. Alternatively, we can leave the code in Geronimo sandbox 
>>> while
>>> Sangjin and Rick transition their focus to the Mina 2.x support.
>>>
>>> Will leave it to the Mina project, Rick, and Sangjin to say what 
>>> makes the
>>> most sense.
>>>
>>>     
>>
>> I think all options are open for us.
>>
>> Thanks for your help towards fostering greater community.
>>
>> Alex
>>
>>   

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Rick McGuire <ri...@gmail.com>]

Alex Karasulu wrote:
> Kevan,
>
> Thanks for taking the time to respond.  More inline ...
>
> On Jan 30, 2008 1:08 AM, Kevan Miller <ke...@gmail.com> wrote:
> ...
>
>   
>> So, as we discussed the last time, the community members that have been
>> active in this area are Jeff Genender, Sangjin Lee, and Rick McGuire. You
>> already know Jeff. Have you reached out to Sangjin and Rick?
>> I'd urge them both to become involved in the Mina community, as their time
>> and interest permit.
>>
>>     
>
> Right very good point.
>
> So Sangjin and Rick are you interested in working on this with the rest of
> the asyncweb crew at MINA?
>   
Yes, I'm definitely interested in helping out.  Right now, I'm having a 
hard time figuring which is the correct Mina 2.0 version.  There appear 
to be at least 3 different versions of an AsyncHttpClient floating 
around (one in the Mina trunk, one in the AsyncWeb tree, one in the 
Geronimo sandbox).  Which is the appropriate one to start porting the 
recent changes to the 1.1.5 version to?

Rick


>
>   
>> I can understand, however, if Rick and Sangjin see value in the current
>> codebase
>>
>>     
>
> NP that's something to consider and evaluate.  And regardless of the code in
> general we can share knowledge and expertise.  I'm sure experiences will rub
> off and this is the most important part of it.  The code here is small
> compared to the collaborative potential.
>
>
>   
>> So, one possible solution that occurs to me is to transfer the current
>> 1.1.x code in Geronimo sandbox to the Mina project. This might allow Rick
>> and Sangjin to complete their work on the current codebase and also ease
>> their transition towards merging code and fixes into the Mina 2.xcodebase. Alternatively, we can leave the code in Geronimo sandbox while
>> Sangjin and Rick transition their focus to the Mina 2.x support.
>>
>> Will leave it to the Mina project, Rick, and Sangjin to say what makes the
>> most sense.
>>
>>     
>
> I think all options are open for us.
>
> Thanks for your help towards fostering greater community.
>
> Alex
>
>   

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Sangjin Lee <sj...@gmail.com>]

Yes, I am very interested in working with you guys on this.  I'll work with
Rick.  For your information, the following is the list of JIRA issues that
were submitted and resolved on the Geronimo AHC.  I suspect pretty much all
of them will be relevant.
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10220&component=12312053&sorter/field=issuekey&sorter/order=DESC

Thanks,
Sangjin

On Jan 29, 2008 10:53 PM, Trustin Lee <tr...@gmail.com> wrote:

> On Jan 30, 2008 3:44 PM, Alex Karasulu <ak...@apache.org> wrote:
> > Kevan,
> >
> > Thanks for taking the time to respond.  More inline ...
> >
> > On Jan 30, 2008 1:08 AM, Kevan Miller <ke...@gmail.com> wrote:
> > ...
> >
> > >
> > > So, as we discussed the last time, the community members that have
> been
> > > active in this area are Jeff Genender, Sangjin Lee, and Rick McGuire.
> You
> > > already know Jeff. Have you reached out to Sangjin and Rick?
> > > I'd urge them both to become involved in the Mina community, as their
> time
> > > and interest permit.
> > >
> >
> > Right very good point.
> >
> > So Sangjin and Rick are you interested in working on this with the rest
> of
> > the asyncweb crew at MINA?
>
> In the previous mailing list communication, Sangjin showed his
> interest IIRC.  Probably Rick is too?
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Trustin Lee <tr...@gmail.com>]

On Jan 30, 2008 3:44 PM, Alex Karasulu <ak...@apache.org> wrote:
> Kevan,
>
> Thanks for taking the time to respond.  More inline ...
>
> On Jan 30, 2008 1:08 AM, Kevan Miller <ke...@gmail.com> wrote:
> ...
>
> >
> > So, as we discussed the last time, the community members that have been
> > active in this area are Jeff Genender, Sangjin Lee, and Rick McGuire. You
> > already know Jeff. Have you reached out to Sangjin and Rick?
> > I'd urge them both to become involved in the Mina community, as their time
> > and interest permit.
> >
>
> Right very good point.
>
> So Sangjin and Rick are you interested in working on this with the rest of
> the asyncweb crew at MINA?

In the previous mailing list communication, Sangjin showed his
interest IIRC.  Probably Rick is too?

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Alex Karasulu <ak...@apache.org>]

Kevan,

Thanks for taking the time to respond.  More inline ...

On Jan 30, 2008 1:08 AM, Kevan Miller <ke...@gmail.com> wrote:
...

>
> So, as we discussed the last time, the community members that have been
> active in this area are Jeff Genender, Sangjin Lee, and Rick McGuire. You
> already know Jeff. Have you reached out to Sangjin and Rick?
> I'd urge them both to become involved in the Mina community, as their time
> and interest permit.
>

Right very good point.

So Sangjin and Rick are you interested in working on this with the rest of
the asyncweb crew at MINA?


>
> I can understand, however, if Rick and Sangjin see value in the current
> codebase
>

NP that's something to consider and evaluate.  And regardless of the code in
general we can share knowledge and expertise.  I'm sure experiences will rub
off and this is the most important part of it.  The code here is small
compared to the collaborative potential.


>
> So, one possible solution that occurs to me is to transfer the current
> 1.1.x code in Geronimo sandbox to the Mina project. This might allow Rick
> and Sangjin to complete their work on the current codebase and also ease
> their transition towards merging code and fixes into the Mina 2.xcodebase. Alternatively, we can leave the code in Geronimo sandbox while
> Sangjin and Rick transition their focus to the Mina 2.x support.
>
> Will leave it to the Mina project, Rick, and Sangjin to say what makes the
> most sense.
>

I think all options are open for us.

Thanks for your help towards fostering greater community.

Alex

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Alex Karasulu <ak...@apache.org>]

Kevan,

Thanks for taking the time to respond.  More inline ...

On Jan 30, 2008 1:08 AM, Kevan Miller <ke...@gmail.com> wrote:
...

>
> So, as we discussed the last time, the community members that have been
> active in this area are Jeff Genender, Sangjin Lee, and Rick McGuire. You
> already know Jeff. Have you reached out to Sangjin and Rick?
> I'd urge them both to become involved in the Mina community, as their time
> and interest permit.
>

Right very good point.

So Sangjin and Rick are you interested in working on this with the rest of
the asyncweb crew at MINA?


>
> I can understand, however, if Rick and Sangjin see value in the current
> codebase
>

NP that's something to consider and evaluate.  And regardless of the code in
general we can share knowledge and expertise.  I'm sure experiences will rub
off and this is the most important part of it.  The code here is small
compared to the collaborative potential.


>
> So, one possible solution that occurs to me is to transfer the current
> 1.1.x code in Geronimo sandbox to the Mina project. This might allow Rick
> and Sangjin to complete their work on the current codebase and also ease
> their transition towards merging code and fixes into the Mina 2.xcodebase. Alternatively, we can leave the code in Geronimo sandbox while
> Sangjin and Rick transition their focus to the Mina 2.x support.
>
> Will leave it to the Mina project, Rick, and Sangjin to say what makes the
> most sense.
>

I think all options are open for us.

Thanks for your help towards fostering greater community.

Alex

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender <jg...@apache.org>]

Actually I already made a Mina 2.x version that is in the G sandbox ;-)

Jeff

Kevan Miller wrote:
> 
> On Jan 29, 2008, at 7:28 PM, Mike Heath wrote:
> 
>> Alex Karasulu wrote:
>>> Hi,
>>>
>>> Please excuse the cross post but it's quite necessary. Furthermore 
>>> people
>>> should not feel like they cannot cross post responses so please feel 
>>> free.
>>>
>>> It looks like the two versions of the http client based on MINA are 
>>> starting
>>> to diverge.  I've noticed the other day that some of the fixes for bugs
>>> already solved by one group are being re-implement all over again 
>>> over again
>>> by another.  It's a shame to have that happen so perhaps we can take 
>>> some
>>> concrete steps to prevent this divergence from progressing.
>>>
>>> As a first step I've cleaned up and restructured the Asyncweb code 
>>> base and
>>> posted this email here on the new directory structure in Subversion:
>>>
>>>  *http://tinyurl.com/ypmbd3
>>>
>>> *So I'm sending out this cross post in the hopes of bringing the two 
>>> groups
>>> together as one unified community which apparently has the same goal in
>>> mind: a fast low-resource consuming asynchronous http client.  What 
>>> ever it
>>> takes, I'm sure the MINA PMC is more than willing to accommodate.  If 
>>> you
>>> have trusted committers already working on this in the Geronimo 
>>> community
>>> there is no reason why we cannot trust them to continue working on it 
>>> here
>>> at MINA's Asyncweb project.  Let's open up discussions on this.
>>
>> I totally agree with Alex on this.  It looks there are fixes in the G
>> branch that haven't made it to the MINA branch.  How can bridge the gap
>> in communication as well as the gap in bug fixing?
>>
>> My opinion is that we need to stop all work on the G sandbox branch and
>> move all work over to MINA.  Is there anything impeding that? ...besides
>> a lot of work merging the changes...
> 
> Thanks Alex and Mike.
> 
> So, as we discussed the last time, the community members that have been 
> active in this area are Jeff Genender, Sangjin Lee, and Rick McGuire. 
> You already know Jeff. Have you reached out to Sangjin and Rick? I'd 
> urge them both to become involved in the Mina community, as their time 
> and interest permit.
> 
> Personally, I'm certainly in favor of seeing a united effort in creating 
> an async http client. Mina would seem to be a natural home for this 
> support (since Mina 2.x is moving up the stack and implementing 
> protocols). I think our community would be quite happy to receive this 
> capability by consumng Mina technology. Given the current state of our 
> two projects, I think it's somewhat doubtful that the Geronimo project 
> will end up releasing the AsyncHTTPClient code in our sandbox.
> 
> I can understand, however, if Rick and Sangjin see value in the current 
> codebase -- being based on a released version of Mina (1.1.2)  and 
> perhaps at a different point in terms of stability and function. I 
> suspect that this might be part of the reason why they haven't become 
> involved in the 2.x development work occurring at Mina.
> 
> So, one possible solution that occurs to me is to transfer the current 
> 1.1.x code in Geronimo sandbox to the Mina project. This might allow 
> Rick and Sangjin to complete their work on the current codebase and also 
> ease their transition towards merging code and fixes into the Mina 2.x 
> codebase. Alternatively, we can leave the code in Geronimo sandbox while 
> Sangjin and Rick transition their focus to the Mina 2.x support.
> 
> Will leave it to the Mina project, Rick, and Sangjin to say what makes 
> the most sense.
> 
> --kevan
> 
> 
> 
> 
> 
> 
> 
> 
> 

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Kevan Miller <ke...@gmail.com>]

On Jan 29, 2008, at 7:28 PM, Mike Heath wrote:

> Alex Karasulu wrote:
>> Hi,
>>
>> Please excuse the cross post but it's quite necessary. Furthermore  
>> people
>> should not feel like they cannot cross post responses so please  
>> feel free.
>>
>> It looks like the two versions of the http client based on MINA are  
>> starting
>> to diverge.  I've noticed the other day that some of the fixes for  
>> bugs
>> already solved by one group are being re-implement all over again  
>> over again
>> by another.  It's a shame to have that happen so perhaps we can  
>> take some
>> concrete steps to prevent this divergence from progressing.
>>
>> As a first step I've cleaned up and restructured the Asyncweb code  
>> base and
>> posted this email here on the new directory structure in Subversion:
>>
>>  *http://tinyurl.com/ypmbd3
>>
>> *So I'm sending out this cross post in the hopes of bringing the  
>> two groups
>> together as one unified community which apparently has the same  
>> goal in
>> mind: a fast low-resource consuming asynchronous http client.  What  
>> ever it
>> takes, I'm sure the MINA PMC is more than willing to accommodate.   
>> If you
>> have trusted committers already working on this in the Geronimo  
>> community
>> there is no reason why we cannot trust them to continue working on  
>> it here
>> at MINA's Asyncweb project.  Let's open up discussions on this.
>
> I totally agree with Alex on this.  It looks there are fixes in the G
> branch that haven't made it to the MINA branch.  How can bridge the  
> gap
> in communication as well as the gap in bug fixing?
>
> My opinion is that we need to stop all work on the G sandbox branch  
> and
> move all work over to MINA.  Is there anything impeding  
> that? ...besides
> a lot of work merging the changes...

Thanks Alex and Mike.

So, as we discussed the last time, the community members that have  
been active in this area are Jeff Genender, Sangjin Lee, and Rick  
McGuire. You already know Jeff. Have you reached out to Sangjin and  
Rick? I'd urge them both to become involved in the Mina community, as  
their time and interest permit.

Personally, I'm certainly in favor of seeing a united effort in  
creating an async http client. Mina would seem to be a natural home  
for this support (since Mina 2.x is moving up the stack and  
implementing protocols). I think our community would be quite happy to  
receive this capability by consumng Mina technology. Given the current  
state of our two projects, I think it's somewhat doubtful that the  
Geronimo project will end up releasing the AsyncHTTPClient code in our  
sandbox.

I can understand, however, if Rick and Sangjin see value in the  
current codebase -- being based on a released version of Mina (1.1.2)   
and perhaps at a different point in terms of stability and function. I  
suspect that this might be part of the reason why they haven't become  
involved in the 2.x development work occurring at Mina.

So, one possible solution that occurs to me is to transfer the current  
1.1.x code in Geronimo sandbox to the Mina project. This might allow  
Rick and Sangjin to complete their work on the current codebase and  
also ease their transition towards merging code and fixes into the  
Mina 2.x codebase. Alternatively, we can leave the code in Geronimo  
sandbox while Sangjin and Rick transition their focus to the Mina 2.x  
support.

Will leave it to the Mina project, Rick, and Sangjin to say what makes  
the most sense.

--kevan

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Kevan Miller <ke...@gmail.com>]

On Jan 29, 2008, at 7:28 PM, Mike Heath wrote:

> Alex Karasulu wrote:
>> Hi,
>>
>> Please excuse the cross post but it's quite necessary. Furthermore  
>> people
>> should not feel like they cannot cross post responses so please  
>> feel free.
>>
>> It looks like the two versions of the http client based on MINA are  
>> starting
>> to diverge.  I've noticed the other day that some of the fixes for  
>> bugs
>> already solved by one group are being re-implement all over again  
>> over again
>> by another.  It's a shame to have that happen so perhaps we can  
>> take some
>> concrete steps to prevent this divergence from progressing.
>>
>> As a first step I've cleaned up and restructured the Asyncweb code  
>> base and
>> posted this email here on the new directory structure in Subversion:
>>
>>  *http://tinyurl.com/ypmbd3
>>
>> *So I'm sending out this cross post in the hopes of bringing the  
>> two groups
>> together as one unified community which apparently has the same  
>> goal in
>> mind: a fast low-resource consuming asynchronous http client.  What  
>> ever it
>> takes, I'm sure the MINA PMC is more than willing to accommodate.   
>> If you
>> have trusted committers already working on this in the Geronimo  
>> community
>> there is no reason why we cannot trust them to continue working on  
>> it here
>> at MINA's Asyncweb project.  Let's open up discussions on this.
>
> I totally agree with Alex on this.  It looks there are fixes in the G
> branch that haven't made it to the MINA branch.  How can bridge the  
> gap
> in communication as well as the gap in bug fixing?
>
> My opinion is that we need to stop all work on the G sandbox branch  
> and
> move all work over to MINA.  Is there anything impeding  
> that? ...besides
> a lot of work merging the changes...

Thanks Alex and Mike.

So, as we discussed the last time, the community members that have  
been active in this area are Jeff Genender, Sangjin Lee, and Rick  
McGuire. You already know Jeff. Have you reached out to Sangjin and  
Rick? I'd urge them both to become involved in the Mina community, as  
their time and interest permit.

Personally, I'm certainly in favor of seeing a united effort in  
creating an async http client. Mina would seem to be a natural home  
for this support (since Mina 2.x is moving up the stack and  
implementing protocols). I think our community would be quite happy to  
receive this capability by consumng Mina technology. Given the current  
state of our two projects, I think it's somewhat doubtful that the  
Geronimo project will end up releasing the AsyncHTTPClient code in our  
sandbox.

I can understand, however, if Rick and Sangjin see value in the  
current codebase -- being based on a released version of Mina (1.1.2)   
and perhaps at a different point in terms of stability and function. I  
suspect that this might be part of the reason why they haven't become  
involved in the 2.x development work occurring at Mina.

So, one possible solution that occurs to me is to transfer the current  
1.1.x code in Geronimo sandbox to the Mina project. This might allow  
Rick and Sangjin to complete their work on the current codebase and  
also ease their transition towards merging code and fixes into the  
Mina 2.x codebase. Alternatively, we can leave the code in Geronimo  
sandbox while Sangjin and Rick transition their focus to the Mina 2.x  
support.

Will leave it to the Mina project, Rick, and Sangjin to say what makes  
the most sense.

--kevan

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Mike Heath <mh...@apache.org>]

Alex Karasulu wrote:
> Hi,
> 
> Please excuse the cross post but it's quite necessary. Furthermore people
> should not feel like they cannot cross post responses so please feel free.
> 
> It looks like the two versions of the http client based on MINA are starting
> to diverge.  I've noticed the other day that some of the fixes for bugs
> already solved by one group are being re-implement all over again over again
> by another.  It's a shame to have that happen so perhaps we can take some
> concrete steps to prevent this divergence from progressing.
> 
> As a first step I've cleaned up and restructured the Asyncweb code base and
> posted this email here on the new directory structure in Subversion:
> 
>   *http://tinyurl.com/ypmbd3
> 
> *So I'm sending out this cross post in the hopes of bringing the two groups
> together as one unified community which apparently has the same goal in
> mind: a fast low-resource consuming asynchronous http client.  What ever it
> takes, I'm sure the MINA PMC is more than willing to accommodate.  If you
> have trusted committers already working on this in the Geronimo community
> there is no reason why we cannot trust them to continue working on it here
> at MINA's Asyncweb project.  Let's open up discussions on this.

I totally agree with Alex on this.  It looks there are fixes in the G
branch that haven't made it to the MINA branch.  How can bridge the gap
in communication as well as the gap in bug fixing?

My opinion is that we need to stop all work on the G sandbox branch and
move all work over to MINA.  Is there anything impeding that? ...besides
a lot of work merging the changes...

-Mike

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Mike Heath <mh...@apache.org>]

Alex Karasulu wrote:
> Hi,
> 
> Please excuse the cross post but it's quite necessary. Furthermore people
> should not feel like they cannot cross post responses so please feel free.
> 
> It looks like the two versions of the http client based on MINA are starting
> to diverge.  I've noticed the other day that some of the fixes for bugs
> already solved by one group are being re-implement all over again over again
> by another.  It's a shame to have that happen so perhaps we can take some
> concrete steps to prevent this divergence from progressing.
> 
> As a first step I've cleaned up and restructured the Asyncweb code base and
> posted this email here on the new directory structure in Subversion:
> 
>   *http://tinyurl.com/ypmbd3
> 
> *So I'm sending out this cross post in the hopes of bringing the two groups
> together as one unified community which apparently has the same goal in
> mind: a fast low-resource consuming asynchronous http client.  What ever it
> takes, I'm sure the MINA PMC is more than willing to accommodate.  If you
> have trusted committers already working on this in the Geronimo community
> there is no reason why we cannot trust them to continue working on it here
> at MINA's Asyncweb project.  Let's open up discussions on this.

I totally agree with Alex on this.  It looks there are fixes in the G
branch that haven't made it to the MINA branch.  How can bridge the gap
in communication as well as the gap in bug fixing?

My opinion is that we need to stop all work on the G sandbox branch and
move all work over to MINA.  Is there anything impeding that? ...besides
a lot of work merging the changes...

-Mike