Re: [AsyncHttpClient] On bringing the code bases and communities together
On Mon, 04 Feb 2008 22:02:19 -0700 Jeff Genender [EMAIL PROTECTED] 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 rightno 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
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 [EMAIL PROTECTED] wrote: On Mon, 04 Feb 2008 22:02:19 -0700 Jeff Genender [EMAIL PROTECTED] 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 rightno 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
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 [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
Re: [AsyncHttpClient] On bringing the code bases and communities together
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
On Feb 5, 2008 10:07 AM, Alex Karasulu [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On Mon, 04 Feb 2008 22:02:19 -0700 Jeff Genender [EMAIL PROTECTED] 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 rightno 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
Excellent thanks. Alex On Feb 5, 2008 9:50 AM, Maarten Bosteels [EMAIL PROTECTED] wrote: On Feb 5, 2008 10:07 AM, Alex Karasulu [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On Mon, 04 Feb 2008 22:02:19 -0700 Jeff Genender [EMAIL PROTECTED] 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 rightno 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 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
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
Re: [AsyncHttpClient] On bringing the code bases and communities together
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
Re: [AsyncHttpClient] On bringing the code bases and communities together
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
Re: [AsyncHttpClient] On bringing the code bases and communities together
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 [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
Re: [AsyncHttpClient] On bringing the code bases and communities together
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 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
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 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 rightno 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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On Jan 30, 2008 1:49 PM, Jeff Genender [EMAIL PROTECTED] 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
Thanks Rick! This was fast. I'll also take a quick look... Regards, Sangjin On Feb 1, 2008 11:17 AM, Jeff Genender [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On Jan 30, 2008 1:49 PM, Jeff Genender [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] wrote: On Jan 30, 2008 1:49 PM, Jeff Genender [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] wrote: On Jan 30, 2008 1:49 PM, Jeff Genender [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On Jan 30, 2008 1:49 PM, Jeff Genender [EMAIL PROTECTED] 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
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
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 [EMAIL PROTECTED] wrote: On Jan 30, 2008 1:49 PM, Jeff Genender [EMAIL PROTECTED] 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 wrote: Kevan, Thanks for taking the time to respond. More inline ... On Jan 30, 2008 1:08 AM, Kevan Miller [EMAIL PROTECTED] 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, 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 [EMAIL PROTECTED] 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 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 [EMAIL PROTECTED] 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
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=truepid=10220component=12312053sorter/field=issuekeysorter/order=DESC Thanks, Sangjin On Jan 29, 2008 10:53 PM, Trustin Lee [EMAIL PROTECTED] wrote: On Jan 30, 2008 3:44 PM, Alex Karasulu [EMAIL PROTECTED] wrote: Kevan, Thanks for taking the time to respond. More inline ... On Jan 30, 2008 1:08 AM, Kevan Miller [EMAIL PROTECTED] 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
On Jan 30, 2008 1:49 PM, Jeff Genender [EMAIL PROTECTED] 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
[AsyncHttpClient] On bringing the code bases and communities together
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
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
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, Thanks for taking the time to respond. More inline ... On Jan 30, 2008 1:08 AM, Kevan Miller [EMAIL PROTECTED] 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
On Jan 30, 2008 3:44 PM, Alex Karasulu [EMAIL PROTECTED] wrote: Kevan, Thanks for taking the time to respond. More inline ... On Jan 30, 2008 1:08 AM, Kevan Miller [EMAIL PROTECTED] 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
