Re: Asynchronous Http Client donation
Happy to hear that you guys are taking care of all the stuff! :D Let's keep the ball rockin' rolling! Trustin On 8/29/07, Mike Heath [EMAIL PROTECTED] wrote: Excellent news! I'm looking forward to playing with this. Thanks Mark! -Mike Mark wrote: OK. I have checked in mina-filter-codec-http, mina-protocol-client-http and mina-protocol-server-http into the trunk. There is still a lot of commenting that needs to be done, but at least the code in in the baseline and people can start working it. Please let me know what more we need from a code perspective. I will work on the javadoc stuff more tonight. One piece I am not sure about is what needs to be done in order to get the new sub-projects integrated into the developer directions for working on multiple branches in the same Eclipse workspace: http://mina.apache.org/developer-guide.html#DeveloperGuide-WorkingwithMultipleBranchesinOneEclipseWorkspace On 8/27/07, Mark [EMAIL PROTECTED] wrote: I am currently working on the HTTP client piece. Check back later in the day for an update. I will respond to this thread with further information. -- ..Cheers Mark On 8/27/07, Kevin Smeltzer [EMAIL PROTECTED] wrote: Nice! I'm in the latter stages ( or so I say ) of development of a massive multiplayer game that is distributed via an Applet. I have been wondering about using TCP/IP for all data transmission from client to server and vice versa, but there may be problems with people who are playing the game in an applet. Also, applets can only connect to the domain that served the page using TCP/IP. But using HTTP as a transport would hopefully bypass those two problems. And that would be awesome! :-D Kevin On 8/27/07, Jeff Genender [EMAIL PROTECTED] wrote: Kevin Smeltzer wrote: Is this a project for doing transfer through HTTP using Mina? If so it could be very valuable (to me anyways) :-D Yep ;-) On 8/27/07, Mark [EMAIL PROTECTED] wrote: I have been moving things around, creating the 3 separate subprojects. Everything is compiling and seems to be in good shape. I posted a question to the list a couple days ago about javadocs at the class level and have not heard back. Maybe your email and mine will bump this thread and someone can answer my question. Either way, I will check in what I have tonight. I'm on EST -- ..Cheers Mark On 8/27/07, Jeff Genender [EMAIL PROTECTED] wrote: Any status on where we are at with this? I have patches I want to start delivering ;-) Jeff Mike Heath wrote: I don't want to hold up moving this code over. If/when we decide to put it on a different release schedule, moving the module over to a 'commons' repo or something similar will be trivial. So, for the time being, I would be fine if we moved asynchronous http client into MINA as a module. I'm eager to play with this client and I'm very eager to look into using it to create asynchronous web service calls. -Mike Mark wrote: I like Trustin's three module ideas as well. I also think Mike has a valid concern on the release schedule. I would rather get a consensus on this before we move forward. On 8/23/07, Cameron Taggart [EMAIL PROTECTED] wrote: I liked Trustin's three module idea: * mina-filter-codec-http -- common code * mina-protocol-server-http -- asyncweb imported here * mina-protocol-client-http -- AsyncHttpClient imported here Can it be decided later, after the import, whether it should be on the same release cycle as MINA!? Apache Felix has components such as their commons on a different release schedule. I think MINA could do the same if needed. The most important thing I think is to get the code imported right now. Cameron On 8/23/07, Mark [EMAIL PROTECTED] wrote: based on Mike's comments, I am not sure where we want to go with all this. On 8/22/07, Jeff Genender [EMAIL PROTECTED] wrote: Mike and Mark, I did my final commits. Feel free to grab the code. I will hold on further development until it hits the Mina repo. You can find it all here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient/ Thanks, Jeff Mike Heath wrote: Trustin Lee wrote: We might be able to extract common codec from both server and client side into a separate module and let two depend on it, resulting three submodules in total: * mina-filter-codec-http * mina-protocol-server-http * mina-protocol-client-http wdty? Trustin Are you suggesting making the above sub-modules part of MINA itself? I don't like this idea as stated in my previous messages. I don't like tying the release of MINA to the release of HTTP protocol handlers and vice versa. I very much like the idea of extracting common functionality between an HTTP server and
Re: Asynchronous Http Client donation
Excellent news! I'm looking forward to playing with this. Thanks Mark! -Mike Mark wrote: OK. I have checked in mina-filter-codec-http, mina-protocol-client-http and mina-protocol-server-http into the trunk. There is still a lot of commenting that needs to be done, but at least the code in in the baseline and people can start working it. Please let me know what more we need from a code perspective. I will work on the javadoc stuff more tonight. One piece I am not sure about is what needs to be done in order to get the new sub-projects integrated into the developer directions for working on multiple branches in the same Eclipse workspace: http://mina.apache.org/developer-guide.html#DeveloperGuide-WorkingwithMultipleBranchesinOneEclipseWorkspace On 8/27/07, Mark [EMAIL PROTECTED] wrote: I am currently working on the HTTP client piece. Check back later in the day for an update. I will respond to this thread with further information. -- ..Cheers Mark On 8/27/07, Kevin Smeltzer [EMAIL PROTECTED] wrote: Nice! I'm in the latter stages ( or so I say ) of development of a massive multiplayer game that is distributed via an Applet. I have been wondering about using TCP/IP for all data transmission from client to server and vice versa, but there may be problems with people who are playing the game in an applet. Also, applets can only connect to the domain that served the page using TCP/IP. But using HTTP as a transport would hopefully bypass those two problems. And that would be awesome! :-D Kevin On 8/27/07, Jeff Genender [EMAIL PROTECTED] wrote: Kevin Smeltzer wrote: Is this a project for doing transfer through HTTP using Mina? If so it could be very valuable (to me anyways) :-D Yep ;-) On 8/27/07, Mark [EMAIL PROTECTED] wrote: I have been moving things around, creating the 3 separate subprojects. Everything is compiling and seems to be in good shape. I posted a question to the list a couple days ago about javadocs at the class level and have not heard back. Maybe your email and mine will bump this thread and someone can answer my question. Either way, I will check in what I have tonight. I'm on EST -- ..Cheers Mark On 8/27/07, Jeff Genender [EMAIL PROTECTED] wrote: Any status on where we are at with this? I have patches I want to start delivering ;-) Jeff Mike Heath wrote: I don't want to hold up moving this code over. If/when we decide to put it on a different release schedule, moving the module over to a 'commons' repo or something similar will be trivial. So, for the time being, I would be fine if we moved asynchronous http client into MINA as a module. I'm eager to play with this client and I'm very eager to look into using it to create asynchronous web service calls. -Mike Mark wrote: I like Trustin's three module ideas as well. I also think Mike has a valid concern on the release schedule. I would rather get a consensus on this before we move forward. On 8/23/07, Cameron Taggart [EMAIL PROTECTED] wrote: I liked Trustin's three module idea: * mina-filter-codec-http -- common code * mina-protocol-server-http -- asyncweb imported here * mina-protocol-client-http -- AsyncHttpClient imported here Can it be decided later, after the import, whether it should be on the same release cycle as MINA!? Apache Felix has components such as their commons on a different release schedule. I think MINA could do the same if needed. The most important thing I think is to get the code imported right now. Cameron On 8/23/07, Mark [EMAIL PROTECTED] wrote: based on Mike's comments, I am not sure where we want to go with all this. On 8/22/07, Jeff Genender [EMAIL PROTECTED] wrote: Mike and Mark, I did my final commits. Feel free to grab the code. I will hold on further development until it hits the Mina repo. You can find it all here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient/ Thanks, Jeff Mike Heath wrote: Trustin Lee wrote: We might be able to extract common codec from both server and client side into a separate module and let two depend on it, resulting three submodules in total: * mina-filter-codec-http * mina-protocol-server-http * mina-protocol-client-http wdty? Trustin Are you suggesting making the above sub-modules part of MINA itself? I don't like this idea as stated in my previous messages. I don't like tying the release of MINA to the release of HTTP protocol handlers and vice versa. I very much like the idea of extracting common functionality between an HTTP server and HTTP client and having both the client and server depend on the common module. After giving it a lot of thought, I'm of the opinion more now than ever that we should make async-httpclient part of AsyncWeb. They have too much in common to keep them separate IMO. There's no reason that AsyncWeb should be a server only project and IIRC, there were plans made a while ago to
Re: Asynchronous Http Client donation
I have been moving things around, creating the 3 separate subprojects. Everything is compiling and seems to be in good shape. I posted a question to the list a couple days ago about javadocs at the class level and have not heard back. Maybe your email and mine will bump this thread and someone can answer my question. Either way, I will check in what I have tonight. I'm on EST -- ..Cheers Mark On 8/27/07, Jeff Genender [EMAIL PROTECTED] wrote: Any status on where we are at with this? I have patches I want to start delivering ;-) Jeff Mike Heath wrote: I don't want to hold up moving this code over. If/when we decide to put it on a different release schedule, moving the module over to a 'commons' repo or something similar will be trivial. So, for the time being, I would be fine if we moved asynchronous http client into MINA as a module. I'm eager to play with this client and I'm very eager to look into using it to create asynchronous web service calls. -Mike Mark wrote: I like Trustin's three module ideas as well. I also think Mike has a valid concern on the release schedule. I would rather get a consensus on this before we move forward. On 8/23/07, Cameron Taggart [EMAIL PROTECTED] wrote: I liked Trustin's three module idea: * mina-filter-codec-http -- common code * mina-protocol-server-http -- asyncweb imported here * mina-protocol-client-http -- AsyncHttpClient imported here Can it be decided later, after the import, whether it should be on the same release cycle as MINA!? Apache Felix has components such as their commons on a different release schedule. I think MINA could do the same if needed. The most important thing I think is to get the code imported right now. Cameron On 8/23/07, Mark [EMAIL PROTECTED] wrote: based on Mike's comments, I am not sure where we want to go with all this. On 8/22/07, Jeff Genender [EMAIL PROTECTED] wrote: Mike and Mark, I did my final commits. Feel free to grab the code. I will hold on further development until it hits the Mina repo. You can find it all here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient/ Thanks, Jeff Mike Heath wrote: Trustin Lee wrote: We might be able to extract common codec from both server and client side into a separate module and let two depend on it, resulting three submodules in total: * mina-filter-codec-http * mina-protocol-server-http * mina-protocol-client-http wdty? Trustin Are you suggesting making the above sub-modules part of MINA itself? I don't like this idea as stated in my previous messages. I don't like tying the release of MINA to the release of HTTP protocol handlers and vice versa. I very much like the idea of extracting common functionality between an HTTP server and HTTP client and having both the client and server depend on the common module. After giving it a lot of thought, I'm of the opinion more now than ever that we should make async-httpclient part of AsyncWeb. They have too much in common to keep them separate IMO. There's no reason that AsyncWeb should be a server only project and IIRC, there were plans made a while ago to create a client for AsyncWeb. Such a move would also give us a good incentive to finally get AsyncWeb migrated over to MINA. WDYT? -Mike -- ..Cheers Mark
Re: Asynchronous Http Client donation
Is this a project for doing transfer through HTTP using Mina? If so it could be very valuable (to me anyways) :-D On 8/27/07, Mark [EMAIL PROTECTED] wrote: I have been moving things around, creating the 3 separate subprojects. Everything is compiling and seems to be in good shape. I posted a question to the list a couple days ago about javadocs at the class level and have not heard back. Maybe your email and mine will bump this thread and someone can answer my question. Either way, I will check in what I have tonight. I'm on EST -- ..Cheers Mark On 8/27/07, Jeff Genender [EMAIL PROTECTED] wrote: Any status on where we are at with this? I have patches I want to start delivering ;-) Jeff Mike Heath wrote: I don't want to hold up moving this code over. If/when we decide to put it on a different release schedule, moving the module over to a 'commons' repo or something similar will be trivial. So, for the time being, I would be fine if we moved asynchronous http client into MINA as a module. I'm eager to play with this client and I'm very eager to look into using it to create asynchronous web service calls. -Mike Mark wrote: I like Trustin's three module ideas as well. I also think Mike has a valid concern on the release schedule. I would rather get a consensus on this before we move forward. On 8/23/07, Cameron Taggart [EMAIL PROTECTED] wrote: I liked Trustin's three module idea: * mina-filter-codec-http -- common code * mina-protocol-server-http -- asyncweb imported here * mina-protocol-client-http -- AsyncHttpClient imported here Can it be decided later, after the import, whether it should be on the same release cycle as MINA!? Apache Felix has components such as their commons on a different release schedule. I think MINA could do the same if needed. The most important thing I think is to get the code imported right now. Cameron On 8/23/07, Mark [EMAIL PROTECTED] wrote: based on Mike's comments, I am not sure where we want to go with all this. On 8/22/07, Jeff Genender [EMAIL PROTECTED] wrote: Mike and Mark, I did my final commits. Feel free to grab the code. I will hold on further development until it hits the Mina repo. You can find it all here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient/ Thanks, Jeff Mike Heath wrote: Trustin Lee wrote: We might be able to extract common codec from both server and client side into a separate module and let two depend on it, resulting three submodules in total: * mina-filter-codec-http * mina-protocol-server-http * mina-protocol-client-http wdty? Trustin Are you suggesting making the above sub-modules part of MINA itself? I don't like this idea as stated in my previous messages. I don't like tying the release of MINA to the release of HTTP protocol handlers and vice versa. I very much like the idea of extracting common functionality between an HTTP server and HTTP client and having both the client and server depend on the common module. After giving it a lot of thought, I'm of the opinion more now than ever that we should make async-httpclient part of AsyncWeb. They have too much in common to keep them separate IMO. There's no reason that AsyncWeb should be a server only project and IIRC, there were plans made a while ago to create a client for AsyncWeb. Such a move would also give us a good incentive to finally get AsyncWeb migrated over to MINA. WDYT? -Mike -- ..Cheers Mark
Re: Asynchronous Http Client donation
Kevin Smeltzer wrote: Is this a project for doing transfer through HTTP using Mina? If so it could be very valuable (to me anyways) :-D Yep ;-) On 8/27/07, Mark [EMAIL PROTECTED] wrote: I have been moving things around, creating the 3 separate subprojects. Everything is compiling and seems to be in good shape. I posted a question to the list a couple days ago about javadocs at the class level and have not heard back. Maybe your email and mine will bump this thread and someone can answer my question. Either way, I will check in what I have tonight. I'm on EST -- ..Cheers Mark On 8/27/07, Jeff Genender [EMAIL PROTECTED] wrote: Any status on where we are at with this? I have patches I want to start delivering ;-) Jeff Mike Heath wrote: I don't want to hold up moving this code over. If/when we decide to put it on a different release schedule, moving the module over to a 'commons' repo or something similar will be trivial. So, for the time being, I would be fine if we moved asynchronous http client into MINA as a module. I'm eager to play with this client and I'm very eager to look into using it to create asynchronous web service calls. -Mike Mark wrote: I like Trustin's three module ideas as well. I also think Mike has a valid concern on the release schedule. I would rather get a consensus on this before we move forward. On 8/23/07, Cameron Taggart [EMAIL PROTECTED] wrote: I liked Trustin's three module idea: * mina-filter-codec-http -- common code * mina-protocol-server-http -- asyncweb imported here * mina-protocol-client-http -- AsyncHttpClient imported here Can it be decided later, after the import, whether it should be on the same release cycle as MINA!? Apache Felix has components such as their commons on a different release schedule. I think MINA could do the same if needed. The most important thing I think is to get the code imported right now. Cameron On 8/23/07, Mark [EMAIL PROTECTED] wrote: based on Mike's comments, I am not sure where we want to go with all this. On 8/22/07, Jeff Genender [EMAIL PROTECTED] wrote: Mike and Mark, I did my final commits. Feel free to grab the code. I will hold on further development until it hits the Mina repo. You can find it all here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient/ Thanks, Jeff Mike Heath wrote: Trustin Lee wrote: We might be able to extract common codec from both server and client side into a separate module and let two depend on it, resulting three submodules in total: * mina-filter-codec-http * mina-protocol-server-http * mina-protocol-client-http wdty? Trustin Are you suggesting making the above sub-modules part of MINA itself? I don't like this idea as stated in my previous messages. I don't like tying the release of MINA to the release of HTTP protocol handlers and vice versa. I very much like the idea of extracting common functionality between an HTTP server and HTTP client and having both the client and server depend on the common module. After giving it a lot of thought, I'm of the opinion more now than ever that we should make async-httpclient part of AsyncWeb. They have too much in common to keep them separate IMO. There's no reason that AsyncWeb should be a server only project and IIRC, there were plans made a while ago to create a client for AsyncWeb. Such a move would also give us a good incentive to finally get AsyncWeb migrated over to MINA. WDYT? -Mike -- ..Cheers Mark
Re: Asynchronous Http Client donation
I am currently working on the HTTP client piece. Check back later in the day for an update. I will respond to this thread with further information. -- ..Cheers Mark On 8/27/07, Kevin Smeltzer [EMAIL PROTECTED] wrote: Nice! I'm in the latter stages ( or so I say ) of development of a massive multiplayer game that is distributed via an Applet. I have been wondering about using TCP/IP for all data transmission from client to server and vice versa, but there may be problems with people who are playing the game in an applet. Also, applets can only connect to the domain that served the page using TCP/IP. But using HTTP as a transport would hopefully bypass those two problems. And that would be awesome! :-D Kevin On 8/27/07, Jeff Genender [EMAIL PROTECTED] wrote: Kevin Smeltzer wrote: Is this a project for doing transfer through HTTP using Mina? If so it could be very valuable (to me anyways) :-D Yep ;-) On 8/27/07, Mark [EMAIL PROTECTED] wrote: I have been moving things around, creating the 3 separate subprojects. Everything is compiling and seems to be in good shape. I posted a question to the list a couple days ago about javadocs at the class level and have not heard back. Maybe your email and mine will bump this thread and someone can answer my question. Either way, I will check in what I have tonight. I'm on EST -- ..Cheers Mark On 8/27/07, Jeff Genender [EMAIL PROTECTED] wrote: Any status on where we are at with this? I have patches I want to start delivering ;-) Jeff Mike Heath wrote: I don't want to hold up moving this code over. If/when we decide to put it on a different release schedule, moving the module over to a 'commons' repo or something similar will be trivial. So, for the time being, I would be fine if we moved asynchronous http client into MINA as a module. I'm eager to play with this client and I'm very eager to look into using it to create asynchronous web service calls. -Mike Mark wrote: I like Trustin's three module ideas as well. I also think Mike has a valid concern on the release schedule. I would rather get a consensus on this before we move forward. On 8/23/07, Cameron Taggart [EMAIL PROTECTED] wrote: I liked Trustin's three module idea: * mina-filter-codec-http -- common code * mina-protocol-server-http -- asyncweb imported here * mina-protocol-client-http -- AsyncHttpClient imported here Can it be decided later, after the import, whether it should be on the same release cycle as MINA!? Apache Felix has components such as their commons on a different release schedule. I think MINA could do the same if needed. The most important thing I think is to get the code imported right now. Cameron On 8/23/07, Mark [EMAIL PROTECTED] wrote: based on Mike's comments, I am not sure where we want to go with all this. On 8/22/07, Jeff Genender [EMAIL PROTECTED] wrote: Mike and Mark, I did my final commits. Feel free to grab the code. I will hold on further development until it hits the Mina repo. You can find it all here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient/ Thanks, Jeff Mike Heath wrote: Trustin Lee wrote: We might be able to extract common codec from both server and client side into a separate module and let two depend on it, resulting three submodules in total: * mina-filter-codec-http * mina-protocol-server-http * mina-protocol-client-http wdty? Trustin Are you suggesting making the above sub-modules part of MINA itself? I don't like this idea as stated in my previous messages. I don't like tying the release of MINA to the release of HTTP protocol handlers and vice versa. I very much like the idea of extracting common functionality between an HTTP server and HTTP client and having both the client and server depend on the common module. After giving it a lot of thought, I'm of the opinion more now than ever that we should make async-httpclient part of AsyncWeb. They have too much in common to keep them separate IMO. There's no reason that AsyncWeb should be a server only project and IIRC, there were plans made a while ago to create a client for AsyncWeb. Such a move would also give us a good incentive to finally get AsyncWeb migrated over to MINA. WDYT? -Mike -- ..Cheers Mark
Re: Asynchronous Http Client donation
OK. I have checked in mina-filter-codec-http, mina-protocol-client-http and mina-protocol-server-http into the trunk. There is still a lot of commenting that needs to be done, but at least the code in in the baseline and people can start working it. Please let me know what more we need from a code perspective. I will work on the javadoc stuff more tonight. One piece I am not sure about is what needs to be done in order to get the new sub-projects integrated into the developer directions for working on multiple branches in the same Eclipse workspace: http://mina.apache.org/developer-guide.html#DeveloperGuide-WorkingwithMultipleBranchesinOneEclipseWorkspace On 8/27/07, Mark [EMAIL PROTECTED] wrote: I am currently working on the HTTP client piece. Check back later in the day for an update. I will respond to this thread with further information. -- ..Cheers Mark On 8/27/07, Kevin Smeltzer [EMAIL PROTECTED] wrote: Nice! I'm in the latter stages ( or so I say ) of development of a massive multiplayer game that is distributed via an Applet. I have been wondering about using TCP/IP for all data transmission from client to server and vice versa, but there may be problems with people who are playing the game in an applet. Also, applets can only connect to the domain that served the page using TCP/IP. But using HTTP as a transport would hopefully bypass those two problems. And that would be awesome! :-D Kevin On 8/27/07, Jeff Genender [EMAIL PROTECTED] wrote: Kevin Smeltzer wrote: Is this a project for doing transfer through HTTP using Mina? If so it could be very valuable (to me anyways) :-D Yep ;-) On 8/27/07, Mark [EMAIL PROTECTED] wrote: I have been moving things around, creating the 3 separate subprojects. Everything is compiling and seems to be in good shape. I posted a question to the list a couple days ago about javadocs at the class level and have not heard back. Maybe your email and mine will bump this thread and someone can answer my question. Either way, I will check in what I have tonight. I'm on EST -- ..Cheers Mark On 8/27/07, Jeff Genender [EMAIL PROTECTED] wrote: Any status on where we are at with this? I have patches I want to start delivering ;-) Jeff Mike Heath wrote: I don't want to hold up moving this code over. If/when we decide to put it on a different release schedule, moving the module over to a 'commons' repo or something similar will be trivial. So, for the time being, I would be fine if we moved asynchronous http client into MINA as a module. I'm eager to play with this client and I'm very eager to look into using it to create asynchronous web service calls. -Mike Mark wrote: I like Trustin's three module ideas as well. I also think Mike has a valid concern on the release schedule. I would rather get a consensus on this before we move forward. On 8/23/07, Cameron Taggart [EMAIL PROTECTED] wrote: I liked Trustin's three module idea: * mina-filter-codec-http -- common code * mina-protocol-server-http -- asyncweb imported here * mina-protocol-client-http -- AsyncHttpClient imported here Can it be decided later, after the import, whether it should be on the same release cycle as MINA!? Apache Felix has components such as their commons on a different release schedule. I think MINA could do the same if needed. The most important thing I think is to get the code imported right now. Cameron On 8/23/07, Mark [EMAIL PROTECTED] wrote: based on Mike's comments, I am not sure where we want to go with all this. On 8/22/07, Jeff Genender [EMAIL PROTECTED] wrote: Mike and Mark, I did my final commits. Feel free to grab the code. I will hold on further development until it hits the Mina repo. You can find it all here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient/ Thanks, Jeff Mike Heath wrote: Trustin Lee wrote: We might be able to extract common codec from both server and client side into a separate module and let two depend on it, resulting three submodules in total: * mina-filter-codec-http * mina-protocol-server-http * mina-protocol-client-http wdty? Trustin Are you suggesting making the above sub-modules part of MINA itself? I don't like this idea as stated in my previous messages. I don't like tying the release of MINA to the release of HTTP protocol handlers and vice versa. I very much like the idea of extracting common functionality between an HTTP server and HTTP client and having both the client and server depend on
Re: Asynchronous Http Client donation
That works for me On 8/27/07, Jeff Genender [EMAIL PROTECTED] wrote: Excellent! Thanks. Should I just open Jiras and attach my patches? Thanks, Jeff Mark wrote: OK. I have checked in mina-filter-codec-http, mina-protocol-client-http and mina-protocol-server-http into the trunk. There is still a lot of commenting that needs to be done, but at least the code in in the baseline and people can start working it. Please let me know what more we need from a code perspective. I will work on the javadoc stuff more tonight. One piece I am not sure about is what needs to be done in order to get the new sub-projects integrated into the developer directions for working on multiple branches in the same Eclipse workspace: http://mina.apache.org/developer-guide.html#DeveloperGuide-WorkingwithMultipleBranchesinOneEclipseWorkspace On 8/27/07, Mark [EMAIL PROTECTED] wrote: I am currently working on the HTTP client piece. Check back later in the day for an update. I will respond to this thread with further information. -- ..Cheers Mark On 8/27/07, Kevin Smeltzer [EMAIL PROTECTED] wrote: Nice! I'm in the latter stages ( or so I say ) of development of a massive multiplayer game that is distributed via an Applet. I have been wondering about using TCP/IP for all data transmission from client to server and vice versa, but there may be problems with people who are playing the game in an applet. Also, applets can only connect to the domain that served the page using TCP/IP. But using HTTP as a transport would hopefully bypass those two problems. And that would be awesome! :-D Kevin On 8/27/07, Jeff Genender [EMAIL PROTECTED] wrote: Kevin Smeltzer wrote: Is this a project for doing transfer through HTTP using Mina? If so it could be very valuable (to me anyways) :-D Yep ;-) On 8/27/07, Mark [EMAIL PROTECTED] wrote: I have been moving things around, creating the 3 separate subprojects. Everything is compiling and seems to be in good shape. I posted a question to the list a couple days ago about javadocs at the class level and have not heard back. Maybe your email and mine will bump this thread and someone can answer my question. Either way, I will check in what I have tonight. I'm on EST -- ..Cheers Mark On 8/27/07, Jeff Genender [EMAIL PROTECTED] wrote: Any status on where we are at with this? I have patches I want to start delivering ;-) Jeff Mike Heath wrote: I don't want to hold up moving this code over. If/when we decide to put it on a different release schedule, moving the module over to a 'commons' repo or something similar will be trivial. So, for the time being, I would be fine if we moved asynchronous http client into MINA as a module. I'm eager to play with this client and I'm very eager to look into using it to create asynchronous web service calls. -Mike Mark wrote: I like Trustin's three module ideas as well. I also think Mike has a valid concern on the release schedule. I would rather get a consensus on this before we move forward. On 8/23/07, Cameron Taggart [EMAIL PROTECTED] wrote: I liked Trustin's three module idea: * mina-filter-codec-http -- common code * mina-protocol-server-http -- asyncweb imported here * mina-protocol-client-http -- AsyncHttpClient imported here Can it be decided later, after the import, whether it should be on the same release cycle as MINA!? Apache Felix has components such as their commons on a different release schedule. I think MINA could do the same if needed. The most important thing I think is to get the code imported right now. Cameron On 8/23/07, Mark [EMAIL PROTECTED] wrote: based on Mike's comments, I am not sure where we want to go with all this. On 8/22/07, Jeff Genender [EMAIL PROTECTED] wrote: Mike and Mark, I did my final commits. Feel free to grab the code. I will hold on further development until it hits the Mina repo. You can find it all here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient/ Thanks, Jeff Mike Heath wrote: Trustin Lee wrote: We might be able to extract common codec from both server and client side into a separate module and let two depend on it, resulting three submodules in total: * mina-filter-codec-http * mina-protocol-server-http * mina-protocol-client-http wdty? Trustin Are you suggesting making the above sub-modules part of MINA itself? I don't like this idea as stated in my previous messages. I don't like tying the release of MINA to the release of HTTP protocol handlers and vice versa. I very much like the idea of extracting common functionality between an HTTP server and HTTP client and having both the client and server depend on the
Re: Asynchronous Http Client donation
I have a question. For the javadoc that is placed at the top of each class, do we keep what is there(if any), or do we replace/insert the MINA boilerplate information? On 8/23/07, Mike Heath [EMAIL PROTECTED] wrote: I don't want to hold up moving this code over. If/when we decide to put it on a different release schedule, moving the module over to a 'commons' repo or something similar will be trivial. So, for the time being, I would be fine if we moved asynchronous http client into MINA as a module. I'm eager to play with this client and I'm very eager to look into using it to create asynchronous web service calls. -Mike Mark wrote: I like Trustin's three module ideas as well. I also think Mike has a valid concern on the release schedule. I would rather get a consensus on this before we move forward. On 8/23/07, Cameron Taggart [EMAIL PROTECTED] wrote: I liked Trustin's three module idea: * mina-filter-codec-http -- common code * mina-protocol-server-http -- asyncweb imported here * mina-protocol-client-http -- AsyncHttpClient imported here Can it be decided later, after the import, whether it should be on the same release cycle as MINA!? Apache Felix has components such as their commons on a different release schedule. I think MINA could do the same if needed. The most important thing I think is to get the code imported right now. Cameron On 8/23/07, Mark [EMAIL PROTECTED] wrote: based on Mike's comments, I am not sure where we want to go with all this. On 8/22/07, Jeff Genender [EMAIL PROTECTED] wrote: Mike and Mark, I did my final commits. Feel free to grab the code. I will hold on further development until it hits the Mina repo. You can find it all here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient/ Thanks, Jeff Mike Heath wrote: Trustin Lee wrote: We might be able to extract common codec from both server and client side into a separate module and let two depend on it, resulting three submodules in total: * mina-filter-codec-http * mina-protocol-server-http * mina-protocol-client-http wdty? Trustin Are you suggesting making the above sub-modules part of MINA itself? I don't like this idea as stated in my previous messages. I don't like tying the release of MINA to the release of HTTP protocol handlers and vice versa. I very much like the idea of extracting common functionality between an HTTP server and HTTP client and having both the client and server depend on the common module. After giving it a lot of thought, I'm of the opinion more now than ever that we should make async-httpclient part of AsyncWeb. They have too much in common to keep them separate IMO. There's no reason that AsyncWeb should be a server only project and IIRC, there were plans made a while ago to create a client for AsyncWeb. Such a move would also give us a good incentive to finally get AsyncWeb migrated over to MINA. WDYT? -Mike -- ..Cheers Mark -- ..Cheers Mark
Re: Asynchronous Http Client donation
based on Mike's comments, I am not sure where we want to go with all this. On 8/22/07, Jeff Genender [EMAIL PROTECTED] wrote: Mike and Mark, I did my final commits. Feel free to grab the code. I will hold on further development until it hits the Mina repo. You can find it all here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient/ Thanks, Jeff Mike Heath wrote: Trustin Lee wrote: We might be able to extract common codec from both server and client side into a separate module and let two depend on it, resulting three submodules in total: * mina-filter-codec-http * mina-protocol-server-http * mina-protocol-client-http wdty? Trustin Are you suggesting making the above sub-modules part of MINA itself? I don't like this idea as stated in my previous messages. I don't like tying the release of MINA to the release of HTTP protocol handlers and vice versa. I very much like the idea of extracting common functionality between an HTTP server and HTTP client and having both the client and server depend on the common module. After giving it a lot of thought, I'm of the opinion more now than ever that we should make async-httpclient part of AsyncWeb. They have too much in common to keep them separate IMO. There's no reason that AsyncWeb should be a server only project and IIRC, there were plans made a while ago to create a client for AsyncWeb. Such a move would also give us a good incentive to finally get AsyncWeb migrated over to MINA. WDYT? -Mike -- ..Cheers Mark
Re: Asynchronous Http Client donation
I liked Trustin's three module idea: * mina-filter-codec-http -- common code * mina-protocol-server-http -- asyncweb imported here * mina-protocol-client-http -- AsyncHttpClient imported here Can it be decided later, after the import, whether it should be on the same release cycle as MINA!? Apache Felix has components such as their commons on a different release schedule. I think MINA could do the same if needed. The most important thing I think is to get the code imported right now. Cameron On 8/23/07, Mark [EMAIL PROTECTED] wrote: based on Mike's comments, I am not sure where we want to go with all this. On 8/22/07, Jeff Genender [EMAIL PROTECTED] wrote: Mike and Mark, I did my final commits. Feel free to grab the code. I will hold on further development until it hits the Mina repo. You can find it all here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient/ Thanks, Jeff Mike Heath wrote: Trustin Lee wrote: We might be able to extract common codec from both server and client side into a separate module and let two depend on it, resulting three submodules in total: * mina-filter-codec-http * mina-protocol-server-http * mina-protocol-client-http wdty? Trustin Are you suggesting making the above sub-modules part of MINA itself? I don't like this idea as stated in my previous messages. I don't like tying the release of MINA to the release of HTTP protocol handlers and vice versa. I very much like the idea of extracting common functionality between an HTTP server and HTTP client and having both the client and server depend on the common module. After giving it a lot of thought, I'm of the opinion more now than ever that we should make async-httpclient part of AsyncWeb. They have too much in common to keep them separate IMO. There's no reason that AsyncWeb should be a server only project and IIRC, there were plans made a while ago to create a client for AsyncWeb. Such a move would also give us a good incentive to finally get AsyncWeb migrated over to MINA. WDYT? -Mike -- ..Cheers Mark
Re: Asynchronous Http Client donation
I like Trustin's three module ideas as well. I also think Mike has a valid concern on the release schedule. I would rather get a consensus on this before we move forward. On 8/23/07, Cameron Taggart [EMAIL PROTECTED] wrote: I liked Trustin's three module idea: * mina-filter-codec-http -- common code * mina-protocol-server-http -- asyncweb imported here * mina-protocol-client-http -- AsyncHttpClient imported here Can it be decided later, after the import, whether it should be on the same release cycle as MINA!? Apache Felix has components such as their commons on a different release schedule. I think MINA could do the same if needed. The most important thing I think is to get the code imported right now. Cameron On 8/23/07, Mark [EMAIL PROTECTED] wrote: based on Mike's comments, I am not sure where we want to go with all this. On 8/22/07, Jeff Genender [EMAIL PROTECTED] wrote: Mike and Mark, I did my final commits. Feel free to grab the code. I will hold on further development until it hits the Mina repo. You can find it all here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient/ Thanks, Jeff Mike Heath wrote: Trustin Lee wrote: We might be able to extract common codec from both server and client side into a separate module and let two depend on it, resulting three submodules in total: * mina-filter-codec-http * mina-protocol-server-http * mina-protocol-client-http wdty? Trustin Are you suggesting making the above sub-modules part of MINA itself? I don't like this idea as stated in my previous messages. I don't like tying the release of MINA to the release of HTTP protocol handlers and vice versa. I very much like the idea of extracting common functionality between an HTTP server and HTTP client and having both the client and server depend on the common module. After giving it a lot of thought, I'm of the opinion more now than ever that we should make async-httpclient part of AsyncWeb. They have too much in common to keep them separate IMO. There's no reason that AsyncWeb should be a server only project and IIRC, there were plans made a while ago to create a client for AsyncWeb. Such a move would also give us a good incentive to finally get AsyncWeb migrated over to MINA. WDYT? -Mike -- ..Cheers Mark -- ..Cheers Mark
Re: Asynchronous Http Client donation
I don't want to hold up moving this code over. If/when we decide to put it on a different release schedule, moving the module over to a 'commons' repo or something similar will be trivial. So, for the time being, I would be fine if we moved asynchronous http client into MINA as a module. I'm eager to play with this client and I'm very eager to look into using it to create asynchronous web service calls. -Mike Mark wrote: I like Trustin's three module ideas as well. I also think Mike has a valid concern on the release schedule. I would rather get a consensus on this before we move forward. On 8/23/07, Cameron Taggart [EMAIL PROTECTED] wrote: I liked Trustin's three module idea: * mina-filter-codec-http -- common code * mina-protocol-server-http -- asyncweb imported here * mina-protocol-client-http -- AsyncHttpClient imported here Can it be decided later, after the import, whether it should be on the same release cycle as MINA!? Apache Felix has components such as their commons on a different release schedule. I think MINA could do the same if needed. The most important thing I think is to get the code imported right now. Cameron On 8/23/07, Mark [EMAIL PROTECTED] wrote: based on Mike's comments, I am not sure where we want to go with all this. On 8/22/07, Jeff Genender [EMAIL PROTECTED] wrote: Mike and Mark, I did my final commits. Feel free to grab the code. I will hold on further development until it hits the Mina repo. You can find it all here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient/ Thanks, Jeff Mike Heath wrote: Trustin Lee wrote: We might be able to extract common codec from both server and client side into a separate module and let two depend on it, resulting three submodules in total: * mina-filter-codec-http * mina-protocol-server-http * mina-protocol-client-http wdty? Trustin Are you suggesting making the above sub-modules part of MINA itself? I don't like this idea as stated in my previous messages. I don't like tying the release of MINA to the release of HTTP protocol handlers and vice versa. I very much like the idea of extracting common functionality between an HTTP server and HTTP client and having both the client and server depend on the common module. After giving it a lot of thought, I'm of the opinion more now than ever that we should make async-httpclient part of AsyncWeb. They have too much in common to keep them separate IMO. There's no reason that AsyncWeb should be a server only project and IIRC, there were plans made a while ago to create a client for AsyncWeb. Such a move would also give us a good incentive to finally get AsyncWeb migrated over to MINA. WDYT? -Mike -- ..Cheers Mark
Re: Asynchronous Http Client donation
On 8/22/07, Mike Heath [EMAIL PROTECTED] wrote: Mark wrote: Just so we are straight on terminology, what I referred to as a MINA component is what I think you all are calling sub-projects. I will be sure to get this right from now on. These include: mina-example mina-filter-codec-netty mina-filter-compression mina-integration-jmx mina-integration-spring I would say that these are optional components of MINA since they are part of the MINA build and all share the same version. When we do a MINA release we vote on, build, and distribute all of these modules and not just mina-core. I don't think async-httpclient should be tied to this process. I think a better home for async-httpclient would be to create something like https://svn.apache.org/repos/asf/mina/async-httpclient and put 'trunk', 'tags', and 'branches' in there. Then in trunk put a parent pom.xml that builds the 'client' and 'examples' modules. This would make async-httpclient totally independent of the MINA release cycle. Do others see things differently? We might be able to extract common codec from both server and client side into a separate module and let two depend on it, resulting three submodules in total: * mina-filter-codec-http * mina-protocol-server-http * mina-protocol-client-http wdty? Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Asynchronous Http Client donation
sounds good to me. I will work this once Mike lets me know that he has everything checked in. On 8/22/07, Trustin Lee [EMAIL PROTECTED] wrote: On 8/22/07, Mike Heath [EMAIL PROTECTED] wrote: Mark wrote: Just so we are straight on terminology, what I referred to as a MINA component is what I think you all are calling sub-projects. I will be sure to get this right from now on. These include: mina-example mina-filter-codec-netty mina-filter-compression mina-integration-jmx mina-integration-spring I would say that these are optional components of MINA since they are part of the MINA build and all share the same version. When we do a MINA release we vote on, build, and distribute all of these modules and not just mina-core. I don't think async-httpclient should be tied to this process. I think a better home for async-httpclient would be to create something like https://svn.apache.org/repos/asf/mina/async-httpclient and put 'trunk', 'tags', and 'branches' in there. Then in trunk put a parent pom.xml that builds the 'client' and 'examples' modules. This would make async-httpclient totally independent of the MINA release cycle. Do others see things differently? We might be able to extract common codec from both server and client side into a separate module and let two depend on it, resulting three submodules in total: * mina-filter-codec-http * mina-protocol-server-http * mina-protocol-client-http wdty? Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6 -- ..Cheers Mark
RE: Asynchronous Http Client donation
Also, on the asyncweb front - I'm all for this still coming across and getting integrated with this new client (sounds good). If enough people want it in as a sub-project (Which seems to be the case), then it sounds like a good idea. I really don't think much remains to be done for the integration to take place - I just don't have the time right now to do much about it myself :o( However, I certainly put the hours in when it came to getting the release grant from my previous employers (I'm sure a few people round here will remember what a nightmare that was) - so if someone else has the time, and wants to pick up the gauntlet and take the final steps to integrate it in to the mina codebase then it would be great to see :o) Hopefully soon I'll have more free time to start contributing properly again! Dave -Original Message- From: Jeff Genender [mailto:[EMAIL PROTECTED] Sent: 22 August 2007 14:35 To: dev@mina.apache.org Subject: Re: Asynchronous Http Client donation Give me just a teeny-weeny bit more time to get the chunking code checked in and its all yours...I'll ping the list. Jeff Mark wrote: sounds good to me. I will work this once Mike lets me know that he has everything checked in. On 8/22/07, Trustin Lee [EMAIL PROTECTED] wrote: On 8/22/07, Mike Heath [EMAIL PROTECTED] wrote: Mark wrote: Just so we are straight on terminology, what I referred to as a MINA component is what I think you all are calling sub-projects. I will be sure to get this right from now on. These include: mina-example mina-filter-codec-netty mina-filter-compression mina-integration-jmx mina-integration-spring I would say that these are optional components of MINA since they are part of the MINA build and all share the same version. When we do a MINA release we vote on, build, and distribute all of these modules and not just mina-core. I don't think async-httpclient should be tied to this process. I think a better home for async-httpclient would be to create something like https://svn.apache.org/repos/asf/mina/async-httpclient and put 'trunk', 'tags', and 'branches' in there. Then in trunk put a parent pom.xml that builds the 'client' and 'examples' modules. This would make async-httpclient totally independent of the MINA release cycle. Do others see things differently? We might be able to extract common codec from both server and client side into a separate module and let two depend on it, resulting three submodules in total: * mina-filter-codec-http * mina-protocol-server-http * mina-protocol-client-http wdty? Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Asynchronous Http Client donation
Mike and Mark, I did my final commits. Feel free to grab the code. I will hold on further development until it hits the Mina repo. You can find it all here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient/ Thanks, Jeff Mike Heath wrote: Trustin Lee wrote: We might be able to extract common codec from both server and client side into a separate module and let two depend on it, resulting three submodules in total: * mina-filter-codec-http * mina-protocol-server-http * mina-protocol-client-http wdty? Trustin Are you suggesting making the above sub-modules part of MINA itself? I don't like this idea as stated in my previous messages. I don't like tying the release of MINA to the release of HTTP protocol handlers and vice versa. I very much like the idea of extracting common functionality between an HTTP server and HTTP client and having both the client and server depend on the common module. After giving it a lot of thought, I'm of the opinion more now than ever that we should make async-httpclient part of AsyncWeb. They have too much in common to keep them separate IMO. There's no reason that AsyncWeb should be a server only project and IIRC, there were plans made a while ago to create a client for AsyncWeb. Such a move would also give us a good incentive to finally get AsyncWeb migrated over to MINA. WDYT? -Mike
Re: Asynchronous Http Client donation
Let me know when you have moved the code over so I can start submitting patches to it since I am developing against the Geronimo sandbox now. Thanks, Jeff Mark wrote: I created a mina-httpclient component on the trunk. Just working things out, along with an example and I will check things in. On 8/21/07, Mike Heath [EMAIL PROTECTED] wrote: This sounds awesome! I would like to see this as the client part of AsyncWeb for two reasons. First it seams to be a natural fit. Second it might give us a little more incentive to finally get AsycWeb moved over to MINA. -Mike Jeff Genender wrote: Hi, First, I want to say that I am a big fan of Mina. For those who don't know me (which is everyone), I am a committer on Geronimo and have had several people ask about an async http client API to use with our NIO clients with comet for the 2.0 Geronimo server. We have had folks who want to be able to do HTTP calls to 3rd party servers from servlets/web apps to get content, and not tie up a thread while its doing its thing. So I decided to try to whip together an API that was similar to Commons HttpClient, fully asynchronous, but based on Mina...and I think I have 80-90% of it completed. It is here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient For what it's worth...it doesn't seem appropriate for Geronimo. So I would like to donate it to Mina. Please have a look at it and give me feed back for if I have gone down the right path. It can be enhanced greatly as this is just a start, but I think it can be very useful and become a powerful API with everyone moving to NIO. Don't hold back any comments ;-) I would really like to see an API like this and I believe Mina is just perfect for this. Please let me know what you think..and if you don't think its right for Mina..thats ok too ;-) But getting your feedback would be best for me...and making this a community project is even better ;-) Jeff
Re: Asynchronous Http Client donation
will do. BTW, do you have any code that I could use in the mina-examples component? I have the code you wrote up to MINA 2.0 compliance, but I want to provide a sample program as well. Thanks, Mark On 8/21/07, Jeff Genender [EMAIL PROTECTED] wrote: Let me know when you have moved the code over so I can start submitting patches to it since I am developing against the Geronimo sandbox now. Thanks, Jeff Mark wrote: I created a mina-httpclient component on the trunk. Just working things out, along with an example and I will check things in. On 8/21/07, Mike Heath [EMAIL PROTECTED] wrote: This sounds awesome! I would like to see this as the client part of AsyncWeb for two reasons. First it seams to be a natural fit. Second it might give us a little more incentive to finally get AsycWeb moved over to MINA. -Mike Jeff Genender wrote: Hi, First, I want to say that I am a big fan of Mina. For those who don't know me (which is everyone), I am a committer on Geronimo and have had several people ask about an async http client API to use with our NIO clients with comet for the 2.0 Geronimo server. We have had folks who want to be able to do HTTP calls to 3rd party servers from servlets/web apps to get content, and not tie up a thread while its doing its thing. So I decided to try to whip together an API that was similar to Commons HttpClient, fully asynchronous, but based on Mina...and I think I have 80-90% of it completed. It is here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient For what it's worth...it doesn't seem appropriate for Geronimo. So I would like to donate it to Mina. Please have a look at it and give me feed back for if I have gone down the right path. It can be enhanced greatly as this is just a start, but I think it can be very useful and become a powerful API with everyone moving to NIO. Don't hold back any comments ;-) I would really like to see an API like this and I believe Mina is just perfect for this. Please let me know what you think..and if you don't think its right for Mina..thats ok too ;-) But getting your feedback would be best for me...and making this a community project is even better ;-) Jeff -- ..Cheers Mark
Re: Asynchronous Http Client donation
Mark, Have a look look at: src/test/java/org/apache/ahc/AsyncHttpClientTest.java The doConnection() is pretty much an example. Basically, you set up an implementation of the AHCCallback to notify you of a response, set up a HttpRequestMessage for your URI, and then make the call to ahc.connect() and ahc.sendRequest(request). However, I am probably going to get rid of the direct access to the HttpRequestMessage and have folks just set/get on the AsyncHttpClient object, which will act as a proxy to the HttpRequestMessage. This will simplify things. I will also probably get rid of the sendRequest() and have everything happen in the connect() method as a single async call - again to simplify its use. There are a few TODOs I am currently working on. 1) I am working on the HTTP/1.1 chunking (hopefully be done today). 2) Need to handle the HTTP/1.1 100 Continue (should be easy to do). 3) Auto-handle 301 Redirect. 4) Handle proxies. 5) A good timeout implementation. Not sure whether to use the sessionIdle() or use a concurrent timer. Since its a single request/response, sessionIdle() may work fine. 6) Possibly allow handling of streams for very large packets (right now it pulls the entire response into memory - which works for 99% of the use cases). But it would be nice to allow people to get their data moved in chunks. I probably need some input on implementing this efficiently...but I think this is the lowest priority item. 7) Finer grained control over the threading model. Basically allow people to tweak the thread pool or pass in their own to use. What currently works: A) HTTPS/SSL/HTTP submission and response B) Cookie handling C) Header handling D) Parameter handling (web parameters) E) All HTTP request types (GET, POST, etc) D) Text and Binary responses As for the donation's being up to Apache spec...I am already an Apache guy (CLA already on file) and it's coming from Apache into Apache ;-) AFICT I have all of the necessary headers are in the source - hopefully I haven't missed anything. We probably just need to rename the packages, etc, to something more meaningful/appropriate to Mina. Thanks, Jeff Mark wrote: will do. BTW, do you have any code that I could use in the mina-examples component? I have the code you wrote up to MINA 2.0 compliance, but I want to provide a sample program as well. Thanks, Mark On 8/21/07, Jeff Genender [EMAIL PROTECTED] wrote: Let me know when you have moved the code over so I can start submitting patches to it since I am developing against the Geronimo sandbox now. Thanks, Jeff Mark wrote: I created a mina-httpclient component on the trunk. Just working things out, along with an example and I will check things in. On 8/21/07, Mike Heath [EMAIL PROTECTED] wrote: This sounds awesome! I would like to see this as the client part of AsyncWeb for two reasons. First it seams to be a natural fit. Second it might give us a little more incentive to finally get AsycWeb moved over to MINA. -Mike Jeff Genender wrote: Hi, First, I want to say that I am a big fan of Mina. For those who don't know me (which is everyone), I am a committer on Geronimo and have had several people ask about an async http client API to use with our NIO clients with comet for the 2.0 Geronimo server. We have had folks who want to be able to do HTTP calls to 3rd party servers from servlets/web apps to get content, and not tie up a thread while its doing its thing. So I decided to try to whip together an API that was similar to Commons HttpClient, fully asynchronous, but based on Mina...and I think I have 80-90% of it completed. It is here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient For what it's worth...it doesn't seem appropriate for Geronimo. So I would like to donate it to Mina. Please have a look at it and give me feed back for if I have gone down the right path. It can be enhanced greatly as this is just a start, but I think it can be very useful and become a powerful API with everyone moving to NIO. Don't hold back any comments ;-) I would really like to see an API like this and I believe Mina is just perfect for this. Please let me know what you think..and if you don't think its right for Mina..thats ok too ;-) But getting your feedback would be best for me...and making this a community project is even better ;-) Jeff
Re: Asynchronous Http Client donation
I'm wondering where this project should really go. Do we want to make it part of MINA (ie. put it in mina/trunk) or do we want to create a separate subproject that depends on MINA (ie. put it in something like mina/async-httpclient/trunk). I'm concerned about the agility of MINA if we start adding protocol handlers to MINA itself. What if we make a change to MINA that breaks one of our protocol handlers? What if there's a bug in a protocol handler that doesn't affect 99.9% of MINA's user base? Will these problems keep us from making releases? If we fix a major bug in MINA that doesn't affect async-httpclient, do we still release a new version of async-httpclient with MINA because async-httpclient is part of the baseline MINA build? I would rather see async-httpclient be a subproject of MINA and have it reside it's own directory in subversion with its own build and with its own examples separate from the MINA examples. That being said, I would MUCH rather see AsyncWeb finally moved over to MINA as a sub-project and then make async-httpclient part of AsyncWeb. There's certainly going to be a lot of overlap between the two. We should leverage that. -Mike Mark wrote: I created a mina-httpclient component on the trunk. Just working things out, along with an example and I will check things in. On 8/21/07, Mike Heath [EMAIL PROTECTED] wrote: This sounds awesome! I would like to see this as the client part of AsyncWeb for two reasons. First it seams to be a natural fit. Second it might give us a little more incentive to finally get AsycWeb moved over to MINA. -Mike Jeff Genender wrote: Hi, First, I want to say that I am a big fan of Mina. For those who don't know me (which is everyone), I am a committer on Geronimo and have had several people ask about an async http client API to use with our NIO clients with comet for the 2.0 Geronimo server. We have had folks who want to be able to do HTTP calls to 3rd party servers from servlets/web apps to get content, and not tie up a thread while its doing its thing. So I decided to try to whip together an API that was similar to Commons HttpClient, fully asynchronous, but based on Mina...and I think I have 80-90% of it completed. It is here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient For what it's worth...it doesn't seem appropriate for Geronimo. So I would like to donate it to Mina. Please have a look at it and give me feed back for if I have gone down the right path. It can be enhanced greatly as this is just a start, but I think it can be very useful and become a powerful API with everyone moving to NIO. Don't hold back any comments ;-) I would really like to see an API like this and I believe Mina is just perfect for this. Please let me know what you think..and if you don't think its right for Mina..thats ok too ;-) But getting your feedback would be best for me...and making this a community project is even better ;-) Jeff
Re: Asynchronous Http Client donation
Mike, I would concur with you on this. I think a sub-project of its own is good since it can be used as a standalone API (with a dependency on Mina of course). I would recommend that this API be a separate artifact from asyncweb as I think we want the client to be capable of being slit off from the server (for obvious reasons). Jeff Mike Heath wrote: I'm wondering where this project should really go. Do we want to make it part of MINA (ie. put it in mina/trunk) or do we want to create a separate subproject that depends on MINA (ie. put it in something like mina/async-httpclient/trunk). I'm concerned about the agility of MINA if we start adding protocol handlers to MINA itself. What if we make a change to MINA that breaks one of our protocol handlers? What if there's a bug in a protocol handler that doesn't affect 99.9% of MINA's user base? Will these problems keep us from making releases? If we fix a major bug in MINA that doesn't affect async-httpclient, do we still release a new version of async-httpclient with MINA because async-httpclient is part of the baseline MINA build? I would rather see async-httpclient be a subproject of MINA and have it reside it's own directory in subversion with its own build and with its own examples separate from the MINA examples. That being said, I would MUCH rather see AsyncWeb finally moved over to MINA as a sub-project and then make async-httpclient part of AsyncWeb. There's certainly going to be a lot of overlap between the two. We should leverage that. -Mike Mark wrote: I created a mina-httpclient component on the trunk. Just working things out, along with an example and I will check things in. On 8/21/07, Mike Heath [EMAIL PROTECTED] wrote: This sounds awesome! I would like to see this as the client part of AsyncWeb for two reasons. First it seams to be a natural fit. Second it might give us a little more incentive to finally get AsycWeb moved over to MINA. -Mike Jeff Genender wrote: Hi, First, I want to say that I am a big fan of Mina. For those who don't know me (which is everyone), I am a committer on Geronimo and have had several people ask about an async http client API to use with our NIO clients with comet for the 2.0 Geronimo server. We have had folks who want to be able to do HTTP calls to 3rd party servers from servlets/web apps to get content, and not tie up a thread while its doing its thing. So I decided to try to whip together an API that was similar to Commons HttpClient, fully asynchronous, but based on Mina...and I think I have 80-90% of it completed. It is here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient For what it's worth...it doesn't seem appropriate for Geronimo. So I would like to donate it to Mina. Please have a look at it and give me feed back for if I have gone down the right path. It can be enhanced greatly as this is just a start, but I think it can be very useful and become a powerful API with everyone moving to NIO. Don't hold back any comments ;-) I would really like to see an API like this and I believe Mina is just perfect for this. Please let me know what you think..and if you don't think its right for Mina..thats ok too ;-) But getting your feedback would be best for me...and making this a community project is even better ;-) Jeff
Re: Asynchronous Http Client donation
On 8/22/07, Jeff Genender [EMAIL PROTECTED] wrote: Mike, I would concur with you on this. I think a sub-project of its own is good since it can be used as a standalone API (with a dependency on Mina of course). I would recommend that this API be a separate artifact from asyncweb as I think we want the client to be capable of being slit off from the server (for obvious reasons). + 1 here too. and I didn't review the code yet. Too much things to handle these days. Let me get back to you again soon. Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Asynchronous Http Client donation
Just so we are straight on terminology, what I referred to as a MINA component is what I think you all are calling sub-projects. I will be sure to get this right from now on. These include: mina-example mina-filter-codec-netty mina-filter-compression mina-integration-jmx mina-integration-spring My intention is to create a new sub-project called mina-httpclient. Once I get the code up to compliance with the trunk, and an example for mina-example in the trunk, I will check everything in. I never planned on placing this code into mina-core, and would not vote for something like this; it makes no sense. On 8/21/07, Mike Heath [EMAIL PROTECTED] wrote: I'm wondering where this project should really go. Do we want to make it part of MINA (ie. put it in mina/trunk) or do we want to create a separate subproject that depends on MINA (ie. put it in something like mina/async-httpclient/trunk). I'm concerned about the agility of MINA if we start adding protocol handlers to MINA itself. What if we make a change to MINA that breaks one of our protocol handlers? What if there's a bug in a protocol handler that doesn't affect 99.9% of MINA's user base? Will these problems keep us from making releases? If we fix a major bug in MINA that doesn't affect async-httpclient, do we still release a new version of async-httpclient with MINA because async-httpclient is part of the baseline MINA build? I would rather see async-httpclient be a subproject of MINA and have it reside it's own directory in subversion with its own build and with its own examples separate from the MINA examples. That being said, I would MUCH rather see AsyncWeb finally moved over to MINA as a sub-project and then make async-httpclient part of AsyncWeb. There's certainly going to be a lot of overlap between the two. We should leverage that. -Mike Mark wrote: I created a mina-httpclient component on the trunk. Just working things out, along with an example and I will check things in. On 8/21/07, Mike Heath [EMAIL PROTECTED] wrote: This sounds awesome! I would like to see this as the client part of AsyncWeb for two reasons. First it seams to be a natural fit. Second it might give us a little more incentive to finally get AsycWeb moved over to MINA. -Mike Jeff Genender wrote: Hi, First, I want to say that I am a big fan of Mina. For those who don't know me (which is everyone), I am a committer on Geronimo and have had several people ask about an async http client API to use with our NIO clients with comet for the 2.0 Geronimo server. We have had folks who want to be able to do HTTP calls to 3rd party servers from servlets/web apps to get content, and not tie up a thread while its doing its thing. So I decided to try to whip together an API that was similar to Commons HttpClient, fully asynchronous, but based on Mina...and I think I have 80-90% of it completed. It is here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient For what it's worth...it doesn't seem appropriate for Geronimo. So I would like to donate it to Mina. Please have a look at it and give me feed back for if I have gone down the right path. It can be enhanced greatly as this is just a start, but I think it can be very useful and become a powerful API with everyone moving to NIO. Don't hold back any comments ;-) I would really like to see an API like this and I believe Mina is just perfect for this. Please let me know what you think..and if you don't think its right for Mina..thats ok too ;-) But getting your feedback would be best for me...and making this a community project is even better ;-) Jeff -- ..Cheers Mark
Re: Asynchronous Http Client donation
Jeff Genender wrote: I would concur with you on this. I think a sub-project of its own is good since it can be used as a standalone API (with a dependency on Mina of course). I would recommend that this API be a separate artifact from asyncweb as I think we want the client to be capable of being slit off from the server (for obvious reasons). Certainly if you want an HTTP client, it's unlikely that you would want an HTTP server. This, of course, makes sense. I would imagine, however, that there are going to be a lot of similarities between the client and server code (header parsing, cookies support, the many caching options of HTTP/1.1, etc.). That's why I was thinking making it part of AsyncWeb would be a good idea. I don't think the client and server should be distributed in the same artifact either. However, I believe there's a lot to be gained by keeping the the HTTP client and server close together. WDYT? -Mike
Re: Asynchronous Http Client donation
Agreed...if we can split the artifacts, then that is fine with me. Jeff Mike Heath wrote: Jeff Genender wrote: I would concur with you on this. I think a sub-project of its own is good since it can be used as a standalone API (with a dependency on Mina of course). I would recommend that this API be a separate artifact from asyncweb as I think we want the client to be capable of being slit off from the server (for obvious reasons). Certainly if you want an HTTP client, it's unlikely that you would want an HTTP server. This, of course, makes sense. I would imagine, however, that there are going to be a lot of similarities between the client and server code (header parsing, cookies support, the many caching options of HTTP/1.1, etc.). That's why I was thinking making it part of AsyncWeb would be a good idea. I don't think the client and server should be distributed in the same artifact either. However, I believe there's a lot to be gained by keeping the the HTTP client and server close together. WDYT? -Mike
Re: Asynchronous Http Client donation
Mark wrote: Just so we are straight on terminology, what I referred to as a MINA component is what I think you all are calling sub-projects. I will be sure to get this right from now on. These include: mina-example mina-filter-codec-netty mina-filter-compression mina-integration-jmx mina-integration-spring I would say that these are optional components of MINA since they are part of the MINA build and all share the same version. When we do a MINA release we vote on, build, and distribute all of these modules and not just mina-core. I don't think async-httpclient should be tied to this process. I think a better home for async-httpclient would be to create something like https://svn.apache.org/repos/asf/mina/async-httpclient and put 'trunk', 'tags', and 'branches' in there. Then in trunk put a parent pom.xml that builds the 'client' and 'examples' modules. This would make async-httpclient totally independent of the MINA release cycle. Do others see things differently? -Mike
Re: Asynchronous Http Client donation
I am fine with that. Honestly, I can't come up with a great reason for any one particular place so I will go with the majority. On 8/22/07, Mike Heath [EMAIL PROTECTED] wrote: Mark wrote: Just so we are straight on terminology, what I referred to as a MINA component is what I think you all are calling sub-projects. I will be sure to get this right from now on. These include: mina-example mina-filter-codec-netty mina-filter-compression mina-integration-jmx mina-integration-spring I would say that these are optional components of MINA since they are part of the MINA build and all share the same version. When we do a MINA release we vote on, build, and distribute all of these modules and not just mina-core. I don't think async-httpclient should be tied to this process. I think a better home for async-httpclient would be to create something like https://svn.apache.org/repos/asf/mina/async-httpclient and put 'trunk', 'tags', and 'branches' in there. Then in trunk put a parent pom.xml that builds the 'client' and 'examples' modules. This would make async-httpclient totally independent of the MINA release cycle. Do others see things differently? -Mike -- ..Cheers Mark
RE: Asynchronous Http Client donation
Hi, I am sorry if this reply is not exactly what you may be expecting back. I am sure around here there are many experts that will have many more interesting replies then this one. However could you please explain to me (and possible others) what Asynch[ronous] Http Client is, and what are its advantages? If I know exactly what it is then I can imagine ways on how to use it :) Thanks and Regards, Sim085 From: Jeff Genender [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: dev@mina.apache.org Subject: Asynchronous Http Client donation Date: Fri, 17 Aug 2007 20:19:07 -0600 Hi, First, I want to say that I am a big fan of Mina. For those who don't know me (which is everyone), I am a committer on Geronimo and have had several people ask about an async http client API to use with our NIO clients with comet for the 2.0 Geronimo server. We have had folks who want to be able to do HTTP calls to 3rd party servers from servlets/web apps to get content, and not tie up a thread while its doing its thing. So I decided to try to whip together an API that was similar to Commons HttpClient, fully asynchronous, but based on Mina...and I think I have 80-90% of it completed. It is here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient For what it's worth...it doesn't seem appropriate for Geronimo. So I would like to donate it to Mina. Please have a look at it and give me feed back for if I have gone down the right path. It can be enhanced greatly as this is just a start, but I think it can be very useful and become a powerful API with everyone moving to NIO. Don't hold back any comments ;-) I would really like to see an API like this and I believe Mina is just perfect for this. Please let me know what you think..and if you don't think its right for Mina..thats ok too ;-) But getting your feedback would be best for me...and making this a community project is even better ;-) Jeff _ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/
Re: Asynchronous Http Client donation
Simon Aquilina wrote: Hi, I am sorry if this reply is not exactly what you may be expecting back. I am sure around here there are many experts that will have many more interesting replies then this one. However could you please explain to me (and possible others) what Asynch[ronous] Http Client is, and what are its advantages? If I know exactly what it is then I can imagine ways on how to use it :) Sure...I would be happy to explain it. With the movement of web containers to NIO (Ex. Jetty, Tomcat, and AsyncWeb), they are able to handle a lot more throughput and simultaneous connections. For some web applications, the servlets may need to retrieve data from a third party web service or scrape 3rd party HTML to embed in a page, or need to grab content as a proxy, like images or ads or pdf from another server. In these sorts of scenarios, the NIO/Comet in the web server would normally have a thread that is blocking when using a blocking client API (like Commons HttpClient or Sun's HttpURLConnect) to retrieve this data. This could significantly throttle the throughput of the NIO containers. By having an Async Http Client API, the thread could be parked and put into use for something else while the original call is waiting for a connection or a response from the third party server. Jeff Thanks and Regards, Sim085 From: Jeff Genender [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: dev@mina.apache.org Subject: Asynchronous Http Client donation Date: Fri, 17 Aug 2007 20:19:07 -0600 Hi, First, I want to say that I am a big fan of Mina. For those who don't know me (which is everyone), I am a committer on Geronimo and have had several people ask about an async http client API to use with our NIO clients with comet for the 2.0 Geronimo server. We have had folks who want to be able to do HTTP calls to 3rd party servers from servlets/web apps to get content, and not tie up a thread while its doing its thing. So I decided to try to whip together an API that was similar to Commons HttpClient, fully asynchronous, but based on Mina...and I think I have 80-90% of it completed. It is here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient For what it's worth...it doesn't seem appropriate for Geronimo. So I would like to donate it to Mina. Please have a look at it and give me feed back for if I have gone down the right path. It can be enhanced greatly as this is just a start, but I think it can be very useful and become a powerful API with everyone moving to NIO. Don't hold back any comments ;-) I would really like to see an API like this and I believe Mina is just perfect for this. Please let me know what you think..and if you don't think its right for Mina..thats ok too ;-) But getting your feedback would be best for me...and making this a community project is even better ;-) Jeff _ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/
Re: Asynchronous Http Client donation
Thanks for the explanation :) I am no expert in Mina so the source of my questions was mostly made out from curiosity. However from what you explained it seems to be a very good idea :) Thanks again, Sim085 From: Jeff Genender [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: dev@mina.apache.org Subject: Re: Asynchronous Http Client donation Date: Sat, 18 Aug 2007 09:32:23 -0600 Simon Aquilina wrote: Hi, I am sorry if this reply is not exactly what you may be expecting back. I am sure around here there are many experts that will have many more interesting replies then this one. However could you please explain to me (and possible others) what Asynch[ronous] Http Client is, and what are its advantages? If I know exactly what it is then I can imagine ways on how to use it :) Sure...I would be happy to explain it. With the movement of web containers to NIO (Ex. Jetty, Tomcat, and AsyncWeb), they are able to handle a lot more throughput and simultaneous connections. For some web applications, the servlets may need to retrieve data from a third party web service or scrape 3rd party HTML to embed in a page, or need to grab content as a proxy, like images or ads or pdf from another server. In these sorts of scenarios, the NIO/Comet in the web server would normally have a thread that is blocking when using a blocking client API (like Commons HttpClient or Sun's HttpURLConnect) to retrieve this data. This could significantly throttle the throughput of the NIO containers. By having an Async Http Client API, the thread could be parked and put into use for something else while the original call is waiting for a connection or a response from the third party server. Jeff Thanks and Regards, Sim085 From: Jeff Genender [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: dev@mina.apache.org Subject: Asynchronous Http Client donation Date: Fri, 17 Aug 2007 20:19:07 -0600 Hi, First, I want to say that I am a big fan of Mina. For those who don't know me (which is everyone), I am a committer on Geronimo and have had several people ask about an async http client API to use with our NIO clients with comet for the 2.0 Geronimo server. We have had folks who want to be able to do HTTP calls to 3rd party servers from servlets/web apps to get content, and not tie up a thread while its doing its thing. So I decided to try to whip together an API that was similar to Commons HttpClient, fully asynchronous, but based on Mina...and I think I have 80-90% of it completed. It is here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient For what it's worth...it doesn't seem appropriate for Geronimo. So I would like to donate it to Mina. Please have a look at it and give me feed back for if I have gone down the right path. It can be enhanced greatly as this is just a start, but I think it can be very useful and become a powerful API with everyone moving to NIO. Don't hold back any comments ;-) I would really like to see an API like this and I believe Mina is just perfect for this. Please let me know what you think..and if you don't think its right for Mina..thats ok too ;-) But getting your feedback would be best for me...and making this a community project is even better ;-) Jeff _ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/ _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
Re: Asynchronous Http Client donation
I will have some free time in the next week or so. I can take the lead on incorporating this into the baseline, if someone wants to give me a good recommendation as to where to place the code. My initial thought is to create a new top level project inside of the trunk. Maybe mina-asynch-httpclient ? On 8/17/07, Jeff Genender [EMAIL PROTECTED] wrote: Hi, First, I want to say that I am a big fan of Mina. For those who don't know me (which is everyone), I am a committer on Geronimo and have had several people ask about an async http client API to use with our NIO clients with comet for the 2.0 Geronimo server. We have had folks who want to be able to do HTTP calls to 3rd party servers from servlets/web apps to get content, and not tie up a thread while its doing its thing. So I decided to try to whip together an API that was similar to Commons HttpClient, fully asynchronous, but based on Mina...and I think I have 80-90% of it completed. It is here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient For what it's worth...it doesn't seem appropriate for Geronimo. So I would like to donate it to Mina. Please have a look at it and give me feed back for if I have gone down the right path. It can be enhanced greatly as this is just a start, but I think it can be very useful and become a powerful API with everyone moving to NIO. Don't hold back any comments ;-) I would really like to see an API like this and I believe Mina is just perfect for this. Please let me know what you think..and if you don't think its right for Mina..thats ok too ;-) But getting your feedback would be best for me...and making this a community project is even better ;-) Jeff -- ..Cheers Mark
Re: Asynchronous Http Client donation
Mark wrote: I will have some free time in the next week or so. I can take the lead on incorporating this into the baseline, if someone wants to give me a good recommendation as to where to place the code. My initial thought is to create a new top level project inside of the trunk. Maybe mina-asynch-httpclient ? +1 from a non-binding person ;-) Jeff On 8/17/07, Jeff Genender [EMAIL PROTECTED] wrote: Hi, First, I want to say that I am a big fan of Mina. For those who don't know me (which is everyone), I am a committer on Geronimo and have had several people ask about an async http client API to use with our NIO clients with comet for the 2.0 Geronimo server. We have had folks who want to be able to do HTTP calls to 3rd party servers from servlets/web apps to get content, and not tie up a thread while its doing its thing. So I decided to try to whip together an API that was similar to Commons HttpClient, fully asynchronous, but based on Mina...and I think I have 80-90% of it completed. It is here: http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient For what it's worth...it doesn't seem appropriate for Geronimo. So I would like to donate it to Mina. Please have a look at it and give me feed back for if I have gone down the right path. It can be enhanced greatly as this is just a start, but I think it can be very useful and become a powerful API with everyone moving to NIO. Don't hold back any comments ;-) I would really like to see an API like this and I believe Mina is just perfect for this. Please let me know what you think..and if you don't think its right for Mina..thats ok too ;-) But getting your feedback would be best for me...and making this a community project is even better ;-) Jeff
