mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [AsyncWeb] build broken w/ last checkin
Date Tue, 18 Mar 2008 18:14:57 GMT

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

> 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'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.

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.

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


View raw message