Re: [AsyncWeb] build broken w/ last checkin
I completely agree that the changes to the 1.0 release should be limited to bug fixes. Thanks, Sangjin On Tue, Mar 18, 2008 at 11:20 AM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Mar 18, 2008, at 11:05 AM, Alex Karasulu wrote: On Tue, Mar 18, 2008 at 1:55 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Mar 18, 2008, at 10:26 AM, Mike Heath wrote: Alex Karasulu wrote: This is your specific situation right? I don't want to leave you hanging but we're really jumping head over heels to make one user comfortable. I think we paved the road for you to be able to achieve what you need by granting you karma to work directly on this code base. We're open but need you to provide a little bit of leeway so we can get everyone on the same base eventually. This move to M2 is a small step in that direction and will have all the Asyncweb modules which include this client on the same MINA dependency. See if you can push back a little to convince your employer of the benefits. At the end of the day, aligning this this community will be as good for you and your employer as it will be for all of us. Let's not be myopic and loose out on gains in the future. Can you try to push this for the project? If AHC is working fine and is tested with MINA 1.1 in it's current state, I don't see any point to pushing to MINA 2.0 just for the sake of moving to MINA 2.0. If AHC has been tested and working well, I don't think we should disrupt that. If we move forward with a new client API as we've been discussing, this new implementation must be based on MINA 2.0 because the AsyncWeb codec is MINA 2.0 based. This reflects my sentiments as well. I think that it's worth nothing that I it us my strongly held belief that everyone is committed to a new and improved v2.0 AHC based on MINA v2.0 and that only patches will be put in the AHC v1.0 branch. Very well I was looking for a compromise here but I don't have the time or wattage to keep discussing this. I spent a lot of time and energy to try to get you guys here to prevent a rift with these forks that would eventually hurt everyone in terms of productivity. Regardless just knowing that people are looking at the big picture for a unified Asyncweb is enough for me to trust that our eyes are on the future as well as the now. I trust that you all value the proper progression of this project so there's no reason for me to worry about it. Your motives make sense and are fair. I agree and will commit to being vehemently opposed to anything other than bug fixes to this proposed v1.0 release. Regards, Alan
Re: [AsyncWeb] build broken w/ last checkin
Alan D. Cabrera wrote: On Mar 18, 2008, at 10:50 AM, Mike Heath wrote: Alan D. Cabrera wrote: On Mar 5, 2008, at 9:03 PM, Mike Heath wrote: Alan D. Cabrera wrote: snip This seems like a good idea. I have some questions. When we cut a release of this code, what version will it be? What will be its Maven group and artifact id? What about the other AsyncWeb client? It looks like people are modifying that quite heavily. Are we going to need to do a pre-2.0 release of that as well? Now you're asking hard questions that I'm not sure I have a good answer for. I think this will take some discussing. To get the discussion started, I'll suggest that for AHC we use the Maven group 'org.apache.asyncweb' and for the artifact id we use 'ahc'. For the version, how about 1.0? For AsyncWeb client, I think we should use the group 'org.apache.asyncweb' and the artifact id 'client'. Seems good to me. What about the work that's currently being done on the old asyncweb client? What are the plans for that? I ask about this because it looks like someone is actively working on it. Will we also have a 1.0 release of org.apache.asyncweb:client? I think we should move the old asyncweb client (a.k.a. AHC) over to a branch in AsyncWeb and continue to maintain it there. Was this ever released? I was referring to the Geronimo sandbox AHC so no I don't think that's ever been released. I think we should release all of AsyncWeb (client, server, codec, extras) together as a 1.0 release. Because both client and server depend heavily on AsyncWeb commons, this makes sense, IMO. When you speak of client, do you mean the old one or the Geronimo one? When I say 'client' I'm referring to the new. In the AsyncWeb client project, I would like to move to the API that we proposed earlier and was discussed on the mailing list. Having code that everyone can see and tinker with will make it easier to facilitate discussion. It's going to take a lot of work and creativity to come up with an API that can accomplish all the things we've been discussing as well as remain consistent between the client and server sides of AsyncWeb. Good idea. Please see an earlier thread that was started about how we can proceed on this. So to summarize: - We move AHC from Geronimo sandbox to a branch in AsyncWeb and maintain it from there (I would like to see an AHC release soon too.) - For AHC we use the group name o.a.asyncweb, the artifact id 'ahc' and the version 1.0 - For the new AsyncWeb client we use the group name o.a.asyncweb and the artifact id 'client' this will also have the version number '1.0' and will be released with the collective AsyncWeb project. I think that we should make it version 2.0. It fits nicely with its MINA 2.0 ties and it more clearly delineates it from the 1.0 release that we're proposing. IMO, simply renaming the artifact id, while still a good idea, is not enough to differentiate the new API. I personally would be fine with this but I don't know how the AsyncWeb server guys would feel about releasing AsyncWeb server under 2.0 without it having a previous release. It does fit well with the MINA 2.0 release. - I'll move the new client API we've been discussing into AsyncWeb client so we start developing it and continue discussing it Please just move the interfaces, per the other discussion on how to proceed, so the community can start submitting examples based on the use cases. I'll post the interfaces to my sandbox for now and we can decide on a permanent home later. It would be good if the HttpConnector was an HttpConnectionFactory w/out the HttpClient factory methods as we discussed. If you still do not agree then I think it's best that we wait until we reach a consensus on these far reaching changes. I believe that I am still waiting for your reply on a number of issues no that old thread. That's how it looks right now. Again, great minds think alike. :) Is everyone ok if we move forward with this plan? Do we need to call for a vote? Wait 72 hours for the discussion to sink in and then call a vote. Ok. -Mike
Re: [AsyncWeb] build broken w/ last checkin
On Mar 5, 2008, at 9:03 PM, Mike Heath wrote: Alan D. Cabrera wrote: snip This seems like a good idea. I have some questions. When we cut a release of this code, what version will it be? What will be its Maven group and artifact id? What about the other AsyncWeb client? It looks like people are modifying that quite heavily. Are we going to need to do a pre-2.0 release of that as well? Now you're asking hard questions that I'm not sure I have a good answer for. I think this will take some discussing. To get the discussion started, I'll suggest that for AHC we use the Maven group 'org.apache.asyncweb' and for the artifact id we use 'ahc'. For the version, how about 1.0? For AsyncWeb client, I think we should use the group 'org.apache.asyncweb' and the artifact id 'client'. Seems good to me. What about the work that's currently being done on the old asyncweb client? What are the plans for that? I ask about this because it looks like someone is actively working on it. Will we also have a 1.0 release of org.apache.asyncweb:client? Regards, Alan
Re: [AsyncWeb] build broken w/ last checkin
This is your specific situation right? I don't want to leave you hanging but we're really jumping head over heels to make one user comfortable. I think we paved the road for you to be able to achieve what you need by granting you karma to work directly on this code base. We're open but need you to provide a little bit of leeway so we can get everyone on the same base eventually. This move to M2 is a small step in that direction and will have all the Asyncweb modules which include this client on the same MINA dependency. See if you can push back a little to convince your employer of the benefits. At the end of the day, aligning this this community will be as good for you and your employer as it will be for all of us. Let's not be myopic and loose out on gains in the future. Can you try to push this for the project? Alex On Thu, Mar 6, 2008 at 1:59 AM, Sangjin Lee [EMAIL PROTECTED] wrote: That might be a problem for us... We're about to use AHC (which is based on mina 1.1.x) in a production environment. Switching to mina 2.0 now would set us back in terms of invested time (testing, regression, etc.)... If at all possible, it would be great if we could support the current AHC as is, while continuing the work on rewriting the client. Thoughts? Regards, Sangjin On Wed, Mar 5, 2008 at 4:05 PM, Alex Karasulu [EMAIL PROTECTED] wrote: You might though want to use MINA 2.0 the move is not that big and it might be the best option. Alex On Wed, Mar 5, 2008 at 6:39 PM, Sangjin Lee [EMAIL PROTECTED] wrote: OK, thanks... I like the suggestion. +1 from me. :) Sangjin On Wed, Mar 5, 2008 at 2:27 PM, Mike Heath [EMAIL PROTECTED] wrote: Sangjin Lee wrote: That sounds like a good idea. Just so I understand, your proposal is to move the existing AHC in the Geronimo sandbox based on mina 1.1.xover to asyncweb under a branch and keep up the maintenance and support on it, right? Thanks, Sangjin Yes, that's exactly what I'm suggesting. -Mike On Tue, Mar 4, 2008 at 2:16 PM, Mike Heath [EMAIL PROTECTED] wrote: Sangjin Lee wrote: I would also like to see asyncweb make progress as quickly as possible, and I'd like to contribute to that effect as well. As Mike pointed out in a different thread, however, there are some challenges to this. It's looking more likely that this is not going to be a simple merge of code but substantial rework. I think part of it stems from the fact that the old AHC relies on its own codec (based on mina 1.1.x) and the asyncweb already has a good codec that's completely different from AHC's. We do have an immediate need to use AHC *now*, and critical bug fixes need to happen, as we're using it right now. But we're making a conscious effort to limit the changes to mostly bug fixes, and we're trying to propagate the changes to asyncweb whenever it is applicable. Those are the things we're doing (or trying to do) to make sure things don't diverge or get out of hand. Why don't we put AHC in a branch in the AsyncWeb Subversion repository? This way AHC can continue using its own codec and we can support and maintain it without going through a lot of work. Once it gets stabilized we could even cut a release. In the mean time, we can continue working toward a revised 2.0 client that uses the AsyncWeb codec. WDYT? -Mike On Tue, Mar 4, 2008 at 6:49 AM, Alex Karasulu [EMAIL PROTECTED] wrote: I am in agreement as well. I would like to see this merge happen quickly so the users see progress and there's no longer any need to keep the G branch alive. Someone said to me you need to get cookin in the kitchen when the guests arrive :). Then we can just start releasing some milestones that people can use and we can track/patch etc. It's nice now that MINA 2.0-m1 is out. This means we can release an Asyncweb milestone as a whole. Also another thing I want people to think about is that this project is one unit rather than just a client. There's a server in there too and we can release it together. The community around this is coming together fast and that's just great which means there's a good potential for graduating this project eventually. These are my hopes for Asyncweb. Alex On Tue, Mar 4, 2008 at 9:33 AM, Jeff Genender [EMAIL PROTECTED] wrote: I agree with Alan...I understood that the G version was going away now that we built community over here on this. Comments? Jeff Alan Cabrera wrote: On
Re: [AsyncWeb] build broken w/ last checkin
BTW, Sangjin, did you get any response from [EMAIL PROTECTED] for your new account? If you didn't get one, please let me know. 2008-03-06 (목), 10:39 -0500, Alex Karasulu 쓰시길: This is your specific situation right? I don't want to leave you hanging but we're really jumping head over heels to make one user comfortable. I think we paved the road for you to be able to achieve what you need by granting you karma to work directly on this code base. We're open but need you to provide a little bit of leeway so we can get everyone on the same base eventually. This move to M2 is a small step in that direction and will have all the Asyncweb modules which include this client on the same MINA dependency. See if you can push back a little to convince your employer of the benefits. At the end of the day, aligning this this community will be as good for you and your employer as it will be for all of us. Let's not be myopic and loose out on gains in the future. Can you try to push this for the project? Alex On Thu, Mar 6, 2008 at 1:59 AM, Sangjin Lee [EMAIL PROTECTED] wrote: That might be a problem for us... We're about to use AHC (which is based on mina 1.1.x) in a production environment. Switching to mina 2.0 now would set us back in terms of invested time (testing, regression, etc.)... If at all possible, it would be great if we could support the current AHC as is, while continuing the work on rewriting the client. Thoughts? Regards, Sangjin On Wed, Mar 5, 2008 at 4:05 PM, Alex Karasulu [EMAIL PROTECTED] wrote: You might though want to use MINA 2.0 the move is not that big and it might be the best option. Alex On Wed, Mar 5, 2008 at 6:39 PM, Sangjin Lee [EMAIL PROTECTED] wrote: OK, thanks... I like the suggestion. +1 from me. :) Sangjin On Wed, Mar 5, 2008 at 2:27 PM, Mike Heath [EMAIL PROTECTED] wrote: Sangjin Lee wrote: That sounds like a good idea. Just so I understand, your proposal is to move the existing AHC in the Geronimo sandbox based on mina 1.1.xover to asyncweb under a branch and keep up the maintenance and support on it, right? Thanks, Sangjin Yes, that's exactly what I'm suggesting. -Mike On Tue, Mar 4, 2008 at 2:16 PM, Mike Heath [EMAIL PROTECTED] wrote: Sangjin Lee wrote: I would also like to see asyncweb make progress as quickly as possible, and I'd like to contribute to that effect as well. As Mike pointed out in a different thread, however, there are some challenges to this. It's looking more likely that this is not going to be a simple merge of code but substantial rework. I think part of it stems from the fact that the old AHC relies on its own codec (based on mina 1.1.x) and the asyncweb already has a good codec that's completely different from AHC's. We do have an immediate need to use AHC *now*, and critical bug fixes need to happen, as we're using it right now. But we're making a conscious effort to limit the changes to mostly bug fixes, and we're trying to propagate the changes to asyncweb whenever it is applicable. Those are the things we're doing (or trying to do) to make sure things don't diverge or get out of hand. Why don't we put AHC in a branch in the AsyncWeb Subversion repository? This way AHC can continue using its own codec and we can support and maintain it without going through a lot of work. Once it gets stabilized we could even cut a release. In the mean time, we can continue working toward a revised 2.0 client that uses the AsyncWeb codec. WDYT? -Mike On Tue, Mar 4, 2008 at 6:49 AM, Alex Karasulu [EMAIL PROTECTED] wrote: I am in agreement as well. I would like to see this merge happen quickly so the users see progress and there's no longer any need to keep the G branch alive. Someone said to me you need to get cookin in the kitchen when the guests arrive :). Then we can just start releasing some milestones that people can use and we can track/patch etc. It's nice now that MINA 2.0-m1 is out. This means we can release an Asyncweb milestone as a whole. Also another thing I want people to think about is that this project is one unit rather than just a client. There's a server in there too and we can release it together. The community around this is coming together fast and that's just great which means there's a good potential for graduating this project eventually.
Re: [AsyncWeb] build broken w/ last checkin
That sounds like a good idea. Just so I understand, your proposal is to move the existing AHC in the Geronimo sandbox based on mina 1.1.x over to asyncweb under a branch and keep up the maintenance and support on it, right? Thanks, Sangjin On Tue, Mar 4, 2008 at 2:16 PM, Mike Heath [EMAIL PROTECTED] wrote: Sangjin Lee wrote: I would also like to see asyncweb make progress as quickly as possible, and I'd like to contribute to that effect as well. As Mike pointed out in a different thread, however, there are some challenges to this. It's looking more likely that this is not going to be a simple merge of code but substantial rework. I think part of it stems from the fact that the old AHC relies on its own codec (based on mina 1.1.x) and the asyncweb already has a good codec that's completely different from AHC's. We do have an immediate need to use AHC *now*, and critical bug fixes need to happen, as we're using it right now. But we're making a conscious effort to limit the changes to mostly bug fixes, and we're trying to propagate the changes to asyncweb whenever it is applicable. Those are the things we're doing (or trying to do) to make sure things don't diverge or get out of hand. Why don't we put AHC in a branch in the AsyncWeb Subversion repository? This way AHC can continue using its own codec and we can support and maintain it without going through a lot of work. Once it gets stabilized we could even cut a release. In the mean time, we can continue working toward a revised 2.0 client that uses the AsyncWeb codec. WDYT? -Mike On Tue, Mar 4, 2008 at 6:49 AM, Alex Karasulu [EMAIL PROTECTED] wrote: I am in agreement as well. I would like to see this merge happen quickly so the users see progress and there's no longer any need to keep the G branch alive. Someone said to me you need to get cookin in the kitchen when the guests arrive :). Then we can just start releasing some milestones that people can use and we can track/patch etc. It's nice now that MINA 2.0-m1 is out. This means we can release an Asyncweb milestone as a whole. Also another thing I want people to think about is that this project is one unit rather than just a client. There's a server in there too and we can release it together. The community around this is coming together fast and that's just great which means there's a good potential for graduating this project eventually. These are my hopes for Asyncweb. Alex On Tue, Mar 4, 2008 at 9:33 AM, Jeff Genender [EMAIL PROTECTED] wrote: I agree with Alan...I understood that the G version was going away now that we built community over here on this. Comments? Jeff Alan Cabrera wrote: On Mar 1, 2008, at 8:12 PM, Alan D. Cabrera wrote: AsyncHttpClient was changed w/ the last checkin on 2/26 and now the build is broken. I looked at the actual changes. I'm just trying to grok the changes because I realize that I am new here. It seems that the old AsyncHttpClient is still evolving? How does this fit in with the plans for the old AsyncHttpClient, the new Geronimo AsyncHttpClient, and the new API that's currently in discussion? I had thought, maybe naively, that we were going to roll the old two into the new one. Regards, Alan
Re: [AsyncWeb] build broken w/ last checkin
Sangjin Lee wrote: That sounds like a good idea. Just so I understand, your proposal is to move the existing AHC in the Geronimo sandbox based on mina 1.1.x over to asyncweb under a branch and keep up the maintenance and support on it, right? Thanks, Sangjin Yes, that's exactly what I'm suggesting. -Mike On Tue, Mar 4, 2008 at 2:16 PM, Mike Heath [EMAIL PROTECTED] wrote: Sangjin Lee wrote: I would also like to see asyncweb make progress as quickly as possible, and I'd like to contribute to that effect as well. As Mike pointed out in a different thread, however, there are some challenges to this. It's looking more likely that this is not going to be a simple merge of code but substantial rework. I think part of it stems from the fact that the old AHC relies on its own codec (based on mina 1.1.x) and the asyncweb already has a good codec that's completely different from AHC's. We do have an immediate need to use AHC *now*, and critical bug fixes need to happen, as we're using it right now. But we're making a conscious effort to limit the changes to mostly bug fixes, and we're trying to propagate the changes to asyncweb whenever it is applicable. Those are the things we're doing (or trying to do) to make sure things don't diverge or get out of hand. Why don't we put AHC in a branch in the AsyncWeb Subversion repository? This way AHC can continue using its own codec and we can support and maintain it without going through a lot of work. Once it gets stabilized we could even cut a release. In the mean time, we can continue working toward a revised 2.0 client that uses the AsyncWeb codec. WDYT? -Mike On Tue, Mar 4, 2008 at 6:49 AM, Alex Karasulu [EMAIL PROTECTED] wrote: I am in agreement as well. I would like to see this merge happen quickly so the users see progress and there's no longer any need to keep the G branch alive. Someone said to me you need to get cookin in the kitchen when the guests arrive :). Then we can just start releasing some milestones that people can use and we can track/patch etc. It's nice now that MINA 2.0-m1 is out. This means we can release an Asyncweb milestone as a whole. Also another thing I want people to think about is that this project is one unit rather than just a client. There's a server in there too and we can release it together. The community around this is coming together fast and that's just great which means there's a good potential for graduating this project eventually. These are my hopes for Asyncweb. Alex On Tue, Mar 4, 2008 at 9:33 AM, Jeff Genender [EMAIL PROTECTED] wrote: I agree with Alan...I understood that the G version was going away now that we built community over here on this. Comments? Jeff Alan Cabrera wrote: On Mar 1, 2008, at 8:12 PM, Alan D. Cabrera wrote: AsyncHttpClient was changed w/ the last checkin on 2/26 and now the build is broken. I looked at the actual changes. I'm just trying to grok the changes because I realize that I am new here. It seems that the old AsyncHttpClient is still evolving? How does this fit in with the plans for the old AsyncHttpClient, the new Geronimo AsyncHttpClient, and the new API that's currently in discussion? I had thought, maybe naively, that we were going to roll the old two into the new one. Regards, Alan
Re: [AsyncWeb] build broken w/ last checkin
OK, thanks... I like the suggestion. +1 from me. :) Sangjin On Wed, Mar 5, 2008 at 2:27 PM, Mike Heath [EMAIL PROTECTED] wrote: Sangjin Lee wrote: That sounds like a good idea. Just so I understand, your proposal is to move the existing AHC in the Geronimo sandbox based on mina 1.1.x over to asyncweb under a branch and keep up the maintenance and support on it, right? Thanks, Sangjin Yes, that's exactly what I'm suggesting. -Mike On Tue, Mar 4, 2008 at 2:16 PM, Mike Heath [EMAIL PROTECTED] wrote: Sangjin Lee wrote: I would also like to see asyncweb make progress as quickly as possible, and I'd like to contribute to that effect as well. As Mike pointed out in a different thread, however, there are some challenges to this. It's looking more likely that this is not going to be a simple merge of code but substantial rework. I think part of it stems from the fact that the old AHC relies on its own codec (based on mina 1.1.x) and the asyncweb already has a good codec that's completely different from AHC's. We do have an immediate need to use AHC *now*, and critical bug fixes need to happen, as we're using it right now. But we're making a conscious effort to limit the changes to mostly bug fixes, and we're trying to propagate the changes to asyncweb whenever it is applicable. Those are the things we're doing (or trying to do) to make sure things don't diverge or get out of hand. Why don't we put AHC in a branch in the AsyncWeb Subversion repository? This way AHC can continue using its own codec and we can support and maintain it without going through a lot of work. Once it gets stabilized we could even cut a release. In the mean time, we can continue working toward a revised 2.0 client that uses the AsyncWeb codec. WDYT? -Mike On Tue, Mar 4, 2008 at 6:49 AM, Alex Karasulu [EMAIL PROTECTED] wrote: I am in agreement as well. I would like to see this merge happen quickly so the users see progress and there's no longer any need to keep the G branch alive. Someone said to me you need to get cookin in the kitchen when the guests arrive :). Then we can just start releasing some milestones that people can use and we can track/patch etc. It's nice now that MINA 2.0-m1 is out. This means we can release an Asyncweb milestone as a whole. Also another thing I want people to think about is that this project is one unit rather than just a client. There's a server in there too and we can release it together. The community around this is coming together fast and that's just great which means there's a good potential for graduating this project eventually. These are my hopes for Asyncweb. Alex On Tue, Mar 4, 2008 at 9:33 AM, Jeff Genender [EMAIL PROTECTED] wrote: I agree with Alan...I understood that the G version was going away now that we built community over here on this. Comments? Jeff Alan Cabrera wrote: On Mar 1, 2008, at 8:12 PM, Alan D. Cabrera wrote: AsyncHttpClient was changed w/ the last checkin on 2/26 and now the build is broken. I looked at the actual changes. I'm just trying to grok the changes because I realize that I am new here. It seems that the old AsyncHttpClient is still evolving? How does this fit in with the plans for the old AsyncHttpClient, the new Geronimo AsyncHttpClient, and the new API that's currently in discussion? I had thought, maybe naively, that we were going to roll the old two into the new one. Regards, Alan
Re: [AsyncWeb] build broken w/ last checkin
You might though want to use MINA 2.0 the move is not that big and it might be the best option. Alex On Wed, Mar 5, 2008 at 6:39 PM, Sangjin Lee [EMAIL PROTECTED] wrote: OK, thanks... I like the suggestion. +1 from me. :) Sangjin On Wed, Mar 5, 2008 at 2:27 PM, Mike Heath [EMAIL PROTECTED] wrote: Sangjin Lee wrote: That sounds like a good idea. Just so I understand, your proposal is to move the existing AHC in the Geronimo sandbox based on mina 1.1.x over to asyncweb under a branch and keep up the maintenance and support on it, right? Thanks, Sangjin Yes, that's exactly what I'm suggesting. -Mike On Tue, Mar 4, 2008 at 2:16 PM, Mike Heath [EMAIL PROTECTED] wrote: Sangjin Lee wrote: I would also like to see asyncweb make progress as quickly as possible, and I'd like to contribute to that effect as well. As Mike pointed out in a different thread, however, there are some challenges to this. It's looking more likely that this is not going to be a simple merge of code but substantial rework. I think part of it stems from the fact that the old AHC relies on its own codec (based on mina 1.1.x) and the asyncweb already has a good codec that's completely different from AHC's. We do have an immediate need to use AHC *now*, and critical bug fixes need to happen, as we're using it right now. But we're making a conscious effort to limit the changes to mostly bug fixes, and we're trying to propagate the changes to asyncweb whenever it is applicable. Those are the things we're doing (or trying to do) to make sure things don't diverge or get out of hand. Why don't we put AHC in a branch in the AsyncWeb Subversion repository? This way AHC can continue using its own codec and we can support and maintain it without going through a lot of work. Once it gets stabilized we could even cut a release. In the mean time, we can continue working toward a revised 2.0 client that uses the AsyncWeb codec. WDYT? -Mike On Tue, Mar 4, 2008 at 6:49 AM, Alex Karasulu [EMAIL PROTECTED] wrote: I am in agreement as well. I would like to see this merge happen quickly so the users see progress and there's no longer any need to keep the G branch alive. Someone said to me you need to get cookin in the kitchen when the guests arrive :). Then we can just start releasing some milestones that people can use and we can track/patch etc. It's nice now that MINA 2.0-m1 is out. This means we can release an Asyncweb milestone as a whole. Also another thing I want people to think about is that this project is one unit rather than just a client. There's a server in there too and we can release it together. The community around this is coming together fast and that's just great which means there's a good potential for graduating this project eventually. These are my hopes for Asyncweb. Alex On Tue, Mar 4, 2008 at 9:33 AM, Jeff Genender [EMAIL PROTECTED] wrote: I agree with Alan...I understood that the G version was going away now that we built community over here on this. Comments? Jeff Alan Cabrera wrote: On Mar 1, 2008, at 8:12 PM, Alan D. Cabrera wrote: AsyncHttpClient was changed w/ the last checkin on 2/26 and now the build is broken. I looked at the actual changes. I'm just trying to grok the changes because I realize that I am new here. It seems that the old AsyncHttpClient is still evolving? How does this fit in with the plans for the old AsyncHttpClient, the new Geronimo AsyncHttpClient, and the new API that's currently in discussion? I had thought, maybe naively, that we were going to roll the old two into the new one. Regards, Alan
Re: [AsyncWeb] build broken w/ last checkin
On Mar 4, 2008, at 2:16 PM, Mike Heath wrote: Sangjin Lee wrote: I would also like to see asyncweb make progress as quickly as possible, and I'd like to contribute to that effect as well. As Mike pointed out in a different thread, however, there are some challenges to this. It's looking more likely that this is not going to be a simple merge of code but substantial rework. I think part of it stems from the fact that the old AHC relies on its own codec (based on mina 1.1.x) and the asyncweb already has a good codec that's completely different from AHC's. We do have an immediate need to use AHC *now*, and critical bug fixes need to happen, as we're using it right now. But we're making a conscious effort to limit the changes to mostly bug fixes, and we're trying to propagate the changes to asyncweb whenever it is applicable. Those are the things we're doing (or trying to do) to make sure things don't diverge or get out of hand. Why don't we put AHC in a branch in the AsyncWeb Subversion repository? This way AHC can continue using its own codec and we can support and maintain it without going through a lot of work. Once it gets stabilized we could even cut a release. In the mean time, we can continue working toward a revised 2.0 client that uses the AsyncWeb codec. WDYT? This seems like a good idea. I have some questions. When we cut a release of this code, what version will it be? What will be its Maven group and artifact id? What about the other AsyncWeb client? It looks like people are modifying that quite heavily. Are we going to need to do a pre-2.0 release of that as well? Regards, Alan
Re: [AsyncWeb] build broken w/ last checkin
Alan D. Cabrera wrote: snip This seems like a good idea. I have some questions. When we cut a release of this code, what version will it be? What will be its Maven group and artifact id? What about the other AsyncWeb client? It looks like people are modifying that quite heavily. Are we going to need to do a pre-2.0 release of that as well? Now you're asking hard questions that I'm not sure I have a good answer for. I think this will take some discussing. To get the discussion started, I'll suggest that for AHC we use the Maven group 'org.apache.asyncweb' and for the artifact id we use 'ahc'. For the version, how about 1.0? For AsyncWeb client, I think we should use the group 'org.apache.asyncweb' and the artifact id 'client'. -Mike
Re: [AsyncWeb] build broken w/ last checkin
That might be a problem for us... We're about to use AHC (which is based on mina 1.1.x) in a production environment. Switching to mina 2.0 now would set us back in terms of invested time (testing, regression, etc.)... If at all possible, it would be great if we could support the current AHC as is, while continuing the work on rewriting the client. Thoughts? Regards, Sangjin On Wed, Mar 5, 2008 at 4:05 PM, Alex Karasulu [EMAIL PROTECTED] wrote: You might though want to use MINA 2.0 the move is not that big and it might be the best option. Alex On Wed, Mar 5, 2008 at 6:39 PM, Sangjin Lee [EMAIL PROTECTED] wrote: OK, thanks... I like the suggestion. +1 from me. :) Sangjin On Wed, Mar 5, 2008 at 2:27 PM, Mike Heath [EMAIL PROTECTED] wrote: Sangjin Lee wrote: That sounds like a good idea. Just so I understand, your proposal is to move the existing AHC in the Geronimo sandbox based on mina 1.1.xover to asyncweb under a branch and keep up the maintenance and support on it, right? Thanks, Sangjin Yes, that's exactly what I'm suggesting. -Mike On Tue, Mar 4, 2008 at 2:16 PM, Mike Heath [EMAIL PROTECTED] wrote: Sangjin Lee wrote: I would also like to see asyncweb make progress as quickly as possible, and I'd like to contribute to that effect as well. As Mike pointed out in a different thread, however, there are some challenges to this. It's looking more likely that this is not going to be a simple merge of code but substantial rework. I think part of it stems from the fact that the old AHC relies on its own codec (based on mina 1.1.x) and the asyncweb already has a good codec that's completely different from AHC's. We do have an immediate need to use AHC *now*, and critical bug fixes need to happen, as we're using it right now. But we're making a conscious effort to limit the changes to mostly bug fixes, and we're trying to propagate the changes to asyncweb whenever it is applicable. Those are the things we're doing (or trying to do) to make sure things don't diverge or get out of hand. Why don't we put AHC in a branch in the AsyncWeb Subversion repository? This way AHC can continue using its own codec and we can support and maintain it without going through a lot of work. Once it gets stabilized we could even cut a release. In the mean time, we can continue working toward a revised 2.0 client that uses the AsyncWeb codec. WDYT? -Mike On Tue, Mar 4, 2008 at 6:49 AM, Alex Karasulu [EMAIL PROTECTED] wrote: I am in agreement as well. I would like to see this merge happen quickly so the users see progress and there's no longer any need to keep the G branch alive. Someone said to me you need to get cookin in the kitchen when the guests arrive :). Then we can just start releasing some milestones that people can use and we can track/patch etc. It's nice now that MINA 2.0-m1 is out. This means we can release an Asyncweb milestone as a whole. Also another thing I want people to think about is that this project is one unit rather than just a client. There's a server in there too and we can release it together. The community around this is coming together fast and that's just great which means there's a good potential for graduating this project eventually. These are my hopes for Asyncweb. Alex On Tue, Mar 4, 2008 at 9:33 AM, Jeff Genender [EMAIL PROTECTED] wrote: I agree with Alan...I understood that the G version was going away now that we built community over here on this. Comments? Jeff Alan Cabrera wrote: On Mar 1, 2008, at 8:12 PM, Alan D. Cabrera wrote: AsyncHttpClient was changed w/ the last checkin on 2/26 and now the build is broken. I looked at the actual changes. I'm just trying to grok the changes because I realize that I am new here. It seems that the old AsyncHttpClient is still evolving? How does this fit in with the plans for the old AsyncHttpClient, the new Geronimo AsyncHttpClient, and the new API that's currently in discussion? I had thought, maybe naively, that we were going to roll the old two into the new one. Regards, Alan
Re: [AsyncWeb] build broken w/ last checkin
I agree with Alan...I understood that the G version was going away now that we built community over here on this. Comments? Jeff Alan Cabrera wrote: On Mar 1, 2008, at 8:12 PM, Alan D. Cabrera wrote: AsyncHttpClient was changed w/ the last checkin on 2/26 and now the build is broken. I looked at the actual changes. I'm just trying to grok the changes because I realize that I am new here. It seems that the old AsyncHttpClient is still evolving? How does this fit in with the plans for the old AsyncHttpClient, the new Geronimo AsyncHttpClient, and the new API that's currently in discussion? I had thought, maybe naively, that we were going to roll the old two into the new one. Regards, Alan
Re: [AsyncWeb] build broken w/ last checkin
I am in agreement as well. I would like to see this merge happen quickly so the users see progress and there's no longer any need to keep the G branch alive. Someone said to me you need to get cookin in the kitchen when the guests arrive :). Then we can just start releasing some milestones that people can use and we can track/patch etc. It's nice now that MINA 2.0-m1 is out. This means we can release an Asyncweb milestone as a whole. Also another thing I want people to think about is that this project is one unit rather than just a client. There's a server in there too and we can release it together. The community around this is coming together fast and that's just great which means there's a good potential for graduating this project eventually. These are my hopes for Asyncweb. Alex On Tue, Mar 4, 2008 at 9:33 AM, Jeff Genender [EMAIL PROTECTED] wrote: I agree with Alan...I understood that the G version was going away now that we built community over here on this. Comments? Jeff Alan Cabrera wrote: On Mar 1, 2008, at 8:12 PM, Alan D. Cabrera wrote: AsyncHttpClient was changed w/ the last checkin on 2/26 and now the build is broken. I looked at the actual changes. I'm just trying to grok the changes because I realize that I am new here. It seems that the old AsyncHttpClient is still evolving? How does this fit in with the plans for the old AsyncHttpClient, the new Geronimo AsyncHttpClient, and the new API that's currently in discussion? I had thought, maybe naively, that we were going to roll the old two into the new one. Regards, Alan
Re: [AsyncWeb] build broken w/ last checkin
I would also like to see asyncweb make progress as quickly as possible, and I'd like to contribute to that effect as well. As Mike pointed out in a different thread, however, there are some challenges to this. It's looking more likely that this is not going to be a simple merge of code but substantial rework. I think part of it stems from the fact that the old AHC relies on its own codec (based on mina 1.1.x) and the asyncweb already has a good codec that's completely different from AHC's. We do have an immediate need to use AHC *now*, and critical bug fixes need to happen, as we're using it right now. But we're making a conscious effort to limit the changes to mostly bug fixes, and we're trying to propagate the changes to asyncweb whenever it is applicable. Those are the things we're doing (or trying to do) to make sure things don't diverge or get out of hand. Regards, Sangjin On Tue, Mar 4, 2008 at 6:49 AM, Alex Karasulu [EMAIL PROTECTED] wrote: I am in agreement as well. I would like to see this merge happen quickly so the users see progress and there's no longer any need to keep the G branch alive. Someone said to me you need to get cookin in the kitchen when the guests arrive :). Then we can just start releasing some milestones that people can use and we can track/patch etc. It's nice now that MINA 2.0-m1 is out. This means we can release an Asyncweb milestone as a whole. Also another thing I want people to think about is that this project is one unit rather than just a client. There's a server in there too and we can release it together. The community around this is coming together fast and that's just great which means there's a good potential for graduating this project eventually. These are my hopes for Asyncweb. Alex On Tue, Mar 4, 2008 at 9:33 AM, Jeff Genender [EMAIL PROTECTED] wrote: I agree with Alan...I understood that the G version was going away now that we built community over here on this. Comments? Jeff Alan Cabrera wrote: On Mar 1, 2008, at 8:12 PM, Alan D. Cabrera wrote: AsyncHttpClient was changed w/ the last checkin on 2/26 and now the build is broken. I looked at the actual changes. I'm just trying to grok the changes because I realize that I am new here. It seems that the old AsyncHttpClient is still evolving? How does this fit in with the plans for the old AsyncHttpClient, the new Geronimo AsyncHttpClient, and the new API that's currently in discussion? I had thought, maybe naively, that we were going to roll the old two into the new one. Regards, Alan
Re: [AsyncWeb] build broken w/ last checkin
Sangjin Lee wrote: I would also like to see asyncweb make progress as quickly as possible, and I'd like to contribute to that effect as well. As Mike pointed out in a different thread, however, there are some challenges to this. It's looking more likely that this is not going to be a simple merge of code but substantial rework. I think part of it stems from the fact that the old AHC relies on its own codec (based on mina 1.1.x) and the asyncweb already has a good codec that's completely different from AHC's. We do have an immediate need to use AHC *now*, and critical bug fixes need to happen, as we're using it right now. But we're making a conscious effort to limit the changes to mostly bug fixes, and we're trying to propagate the changes to asyncweb whenever it is applicable. Those are the things we're doing (or trying to do) to make sure things don't diverge or get out of hand. Why don't we put AHC in a branch in the AsyncWeb Subversion repository? This way AHC can continue using its own codec and we can support and maintain it without going through a lot of work. Once it gets stabilized we could even cut a release. In the mean time, we can continue working toward a revised 2.0 client that uses the AsyncWeb codec. WDYT? -Mike On Tue, Mar 4, 2008 at 6:49 AM, Alex Karasulu [EMAIL PROTECTED] wrote: I am in agreement as well. I would like to see this merge happen quickly so the users see progress and there's no longer any need to keep the G branch alive. Someone said to me you need to get cookin in the kitchen when the guests arrive :). Then we can just start releasing some milestones that people can use and we can track/patch etc. It's nice now that MINA 2.0-m1 is out. This means we can release an Asyncweb milestone as a whole. Also another thing I want people to think about is that this project is one unit rather than just a client. There's a server in there too and we can release it together. The community around this is coming together fast and that's just great which means there's a good potential for graduating this project eventually. These are my hopes for Asyncweb. Alex On Tue, Mar 4, 2008 at 9:33 AM, Jeff Genender [EMAIL PROTECTED] wrote: I agree with Alan...I understood that the G version was going away now that we built community over here on this. Comments? Jeff Alan Cabrera wrote: On Mar 1, 2008, at 8:12 PM, Alan D. Cabrera wrote: AsyncHttpClient was changed w/ the last checkin on 2/26 and now the build is broken. I looked at the actual changes. I'm just trying to grok the changes because I realize that I am new here. It seems that the old AsyncHttpClient is still evolving? How does this fit in with the plans for the old AsyncHttpClient, the new Geronimo AsyncHttpClient, and the new API that's currently in discussion? I had thought, maybe naively, that we were going to roll the old two into the new one. Regards, Alan
Re: [AsyncWeb] build broken w/ last checkin
I noticed this too... Incidentally I also noticed that the SSL unit tests were broken due to the way that the SSL filter is added but that seems to be an old issue. The SSL filter should be added before the protocol codec filter... Shall I file a bug and submit a patch for both? Thanks, Sangjin On Sat, Mar 1, 2008 at 8:12 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: AsyncHttpClient was changed w/ the last checkin on 2/26 and now the build is broken. Regards, Alan
Re: [AsyncWeb] build broken w/ last checkin
Sangjin Lee wrote: I noticed this too... Incidentally I also noticed that the SSL unit tests were broken due to the way that the SSL filter is added but that seems to be an old issue. The SSL filter should be added before the protocol codec filter... Shall I file a bug and submit a patch for both? File a bug and *commit* a patch...you are a committer now ;-) Jeff
Re: [AsyncWeb] build broken w/ last checkin
Not yet... I haven't got an account setup confirmation from ASF... Regards, Sangjin On Mon, Mar 3, 2008 at 12:09 PM, Jeff Genender [EMAIL PROTECTED] wrote: Sangjin Lee wrote: I noticed this too... Incidentally I also noticed that the SSL unit tests were broken due to the way that the SSL filter is added but that seems to be an old issue. The SSL filter should be added before the protocol codec filter... Shall I file a bug and submit a patch for both? File a bug and *commit* a patch...you are a committer now ;-) Jeff
Re: [AsyncWeb] build broken w/ last checkin
I think Trustin sent the request. Sometimes a bunch of them get processed on Wednesdays by Joes. So it's got to be in the queue. If not we can has him on infra what the status is. Alex On Mon, Mar 3, 2008 at 3:17 PM, Jeff Genender [EMAIL PROTECTED] wrote: Hmmm...that is something that should not take long... We need to get this handled ASAP. Alex...any thoughts? Jeff Sangjin Lee wrote: Not yet... I haven't got an account setup confirmation from ASF... Regards, Sangjin On Mon, Mar 3, 2008 at 12:09 PM, Jeff Genender [EMAIL PROTECTED] wrote: Sangjin Lee wrote: I noticed this too... Incidentally I also noticed that the SSL unit tests were broken due to the way that the SSL filter is added but that seems to be an old issue. The SSL filter should be added before the protocol codec filter... Shall I file a bug and submit a patch for both? File a bug and *commit* a patch...you are a committer now ;-) Jeff
Re: [AsyncWeb] build broken w/ last checkin
Jeff Genender wrote: Hmmm...that is something that should not take long... We need to get this handled ASAP. Alex...any thoughts? This usually take a week, sometime more. The account creation request has been sent on feb, 25th. Be patient ;) -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [AsyncWeb] build broken w/ last checkin
Alex Karasulu wrote: I think Trustin sent the request. He did, on feb, 25th... -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [AsyncWeb] build broken w/ last checkin
On Mar 1, 2008, at 8:12 PM, Alan D. Cabrera wrote: AsyncHttpClient was changed w/ the last checkin on 2/26 and now the build is broken. I looked at the actual changes. I'm just trying to grok the changes because I realize that I am new here. It seems that the old AsyncHttpClient is still evolving? How does this fit in with the plans for the old AsyncHttpClient, the new Geronimo AsyncHttpClient, and the new API that's currently in discussion? I had thought, maybe naively, that we were going to roll the old two into the new one. Regards, Alan
[AsyncWeb] build broken w/ last checkin
AsyncHttpClient was changed w/ the last checkin on 2/26 and now the build is broken. Regards, Alan
