You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Alan D. Cabrera" <li...@toolazydogs.com> on 2008/02/09 09:56:38 UTC
[AsyncWeb] Need an async client now
What should I use? I prefer the API from Geronimo but I see that it
doesn't get built in in Mina. I would also prefer to use Mina 1.x and
wait until Mina 2.x shakes itself out.
So, I'm going to toss out the idea of releasing the new API as 1.0 and
we can release the new Mina 2.x based API as 2.0. Thoughts?
Regards,
Alan
Re: [AsyncWeb] Need an async client now
Posted by Mike Heath <mh...@apache.org>.
Alex Karasulu wrote:
<snip>
> IMO I think looking ahead towards the use of MINA 2.0 is the best route here
> and it seems that people have already taken care of the merge. Perhaps
> there's some emails that you may have missed on the commits@ list and here.
> Mike already merged the two I think unless I'm mistaken which may be the
> case since I have been catching up as well.
I'm still working on the merge. It's a lot of work. There are a lot of
very big differences between the AHC codec and the AsyncWeb codec. The
AsyncWeb codec is designed to be independent of the client/server that
uses it while the AHC codec is tightly coupled to the AHC client.
Refactoring AHC to use the AsyncWeb codec has been challenging.
It will be a while before the merge is complete.
> Oh and 1.0 whichever MINA it's based on makes sense to me but jumping
> to 2.0to denote the use of MINA
> 2.0 sounds good too. I just think we should stick to MINA 2.0 through and
> through because of the gains made therein.
I'm of the opinion that we should use MINA 2.0. I think AsyncWeb will
draw a lot of attention to MINA which will help us work out any kinks in
MINA 2.0. MINA 2.0 also has a lot of new features that can be utilized
to minimize the number of threads needed for MINA apps.
-Mike
Re: [AsyncWeb] Need an async client now
Posted by Jeff Genender <jg...@apache.org>.
I agree...I think 2.0 is the way to go...the enhancements really make it
nicer.
Jeff
Alex Karasulu wrote:
> On Feb 9, 2008 12:39 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>> On Feb 9, 2008, at 6:09 AM, Alex Karasulu wrote:
>>
>>> On Feb 9, 2008 3:56 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>
>>>> What should I use? I prefer the API from Geronimo but I see that it
>>>> doesn't get built in in Mina. I would also prefer to use Mina 1.x
>>>> and
>>>> wait until Mina 2.x shakes itself out.
>>>>
>>>> So, I'm going to toss out the idea of releasing the new API as 1.0
>>>> and
>>>> we can release the new Mina 2.x based API as 2.0. Thoughts?
>>>>
>>> IMO I think looking ahead towards the use of MINA 2.0 is the best
>>> route here
>>> and it seems that people have already taken care of the merge.
>>> Perhaps
>>> there's some emails that you may have missed on the commits@ list
>>> and here.
>>> Mike already merged the two I think unless I'm mistaken which may be
>>> the
>>> case since I have been catching up as well.
>> Well, it is in SVN. At the moment there are two clients in there.
>> The newer one does not get added to the Jar artifact per its POM
>> configuration. I really prefer the newer one from Geronimo.
>>
>>> Oh and 1.0 whichever MINA it's based on makes sense to me but jumping
>>> to 2.0 to denote the use of MINA
>>> 2.0 sounds good too. I just think we should stick to MINA 2.0
>>> through and
>>> through because of the gains made therein.
>> Only the Pope and my mother-in-law are infallible. I think that MINA
>> 2.x rocks and will be a resounding success but I think it will take a
>> little bit for things to shake out. IIUC, there's still discussion to
>> fiddle with bits of 2.0.
>>
>> I just want to start w/ MINA 1.x for now. Its characteristics are
>> known and it's been around the block a few times. I am happy to do
>> the scut work for a 1.0 release.
>>
>
> Loved the comment about the Pope and your MIL :). You can always work on a
> 1.0 based version but we're still far from a release as well since the PMC
> is just mobilizing around these new projects. Also note that a MINA
> 2.0release is imminent. Furthermore there's been considerable effort
> put into
> keeping all the people interested in Asyncweb working together towards a
> common goal. Sticking to MINA 2.0 overall will be in the best interest of
> the community. We're seeing great synergy where core MINA folks are working
> closely with the AHC developers. It's really great to see ramping up and
> took a bit of effort.
>
> If there are any hick-ups along the way with MINA 2.0 you have my word and
> I'm sure the word of others' here to resolve them immediately. Fragmenting
> this community into those that work on 1.0 and 2.0 based version of AHC just
> when the collaboration is ramping up would not be good. Please don't
> presume the time frame is going to be longer when based on MINA 2.0.
> Whatever the issue may be for you we'll try our best to accommodate whatever
> it may be. Is there some other problem that you have not mentioned which
> requires a 1.0 release besides just doing it rapidly?
>
> Thanks,
> Alex
>
Re: [AsyncWeb] Need an async client now
Posted by Maarten Bosteels <mb...@gmail.com>.
On Feb 11, 2008 8:20 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> On Feb 11, 2008, at 12:20 AM, Maarten Bosteels wrote:
>
> > On Feb 11, 2008 7:37 AM, Mike Heath <mh...@apache.org> wrote:
> >
> >> The new logging features in SLF4J and removing IoSessionLogger were
> >> what
> >> was holding up an M1 release. Where do we stand on the logging front
> >> right now?
> >
> >
> > see my comments on http://issues.apache.org/jira/browse/DIRMINA-513
> >
> > "IoSessionLogger has been removed, but I could not yet add MDC-aware
> > Formatter implementations because the new SLF4J hasn't been
> > released. "
> >
> > Meanwhile Ceki has published an SLF4J-API-1.5.0-M0 in maven.
> > I will commit the formatter asap (hopefully tonight CET) and close
> > this
> > issue.
>
> Just curious. What are these logging features that are so important?
>
Hello Alan,
see
http://www.nabble.com/Re%3A--MINA--2.0-Milestone-1---p15092056s16868.html
DIRMINA-513 wasn't that important IMO.
But about two weeks ago it was the only unresolved issue for 2.0.0-M1, so we
decided to fix it before cutting the first milestone.
And it's fixed now.
regards,
Maarten
Re: [AsyncWeb] Need an async client now
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Feb 11, 2008, at 12:20 AM, Maarten Bosteels wrote:
> On Feb 11, 2008 7:37 AM, Mike Heath <mh...@apache.org> wrote:
>
>> The new logging features in SLF4J and removing IoSessionLogger were
>> what
>> was holding up an M1 release. Where do we stand on the logging front
>> right now?
>
>
> see my comments on http://issues.apache.org/jira/browse/DIRMINA-513
>
> "IoSessionLogger has been removed, but I could not yet add MDC-aware
> Formatter implementations because the new SLF4J hasn't been
> released. "
>
> Meanwhile Ceki has published an SLF4J-API-1.5.0-M0 in maven.
> I will commit the formatter asap (hopefully tonight CET) and close
> this
> issue.
Just curious. What are these logging features that are so important?
Regards,
Alan
Re: [AsyncWeb] Need an async client now
Posted by Maarten Bosteels <mb...@gmail.com>.
On Feb 11, 2008 7:37 AM, Mike Heath <mh...@apache.org> wrote:
> The new logging features in SLF4J and removing IoSessionLogger were what
> was holding up an M1 release. Where do we stand on the logging front
> right now?
see my comments on http://issues.apache.org/jira/browse/DIRMINA-513
"IoSessionLogger has been removed, but I could not yet add MDC-aware
Formatter implementations because the new SLF4J hasn't been released. "
Meanwhile Ceki has published an SLF4J-API-1.5.0-M0 in maven.
I will commit the formatter asap (hopefully tonight CET) and close this
issue.
Maarten
>
> -Mike
>
> Maarten Bosteels wrote:
> > On Feb 10, 2008 9:05 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> >
> >> On Feb 10, 2008, at 11:35 AM, Maarten Bosteels wrote:
> >>
> >>> Hello,
> >>>
> >>> On Feb 10, 2008 5:28 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> >>>
> >>>> Is it ready? You're only at M1. What are the next milestones
> >>>> planned
> >>>> before you hit beta?
> >>>
> >>> The version numbering scheme is described at the bottom of
> >>> http://mina.apache.org/downloads.html [1]
> >>>
> >>> IMO we should have created 2.0-M0 a few months ago. But for some
> >>> reason we
> >>> have been postponing it as long as there were open JIRA issues that
> >>> could
> >>> require an API change.
> >>>
> >>> According to [1] we are allowed to make API changes between M1 and M2
> >>> but of course it's nicer for the user if we can avoid it.
> >>>
> >>> I just had a look at JIRA at there were more open issues than I
> >>> thought (6)
> >>> but no show-stoppers AFAICS.
> >>>
> >>> Maybe we should have a vote about cutting 2.0-M0 ?
> >> Maybe I'm being dense. You mean 2.0-RC1? When do you guys cut a
> >> branch to stabilize your beta? Does it depend on the situation?
> >>
> >
> > Good question.
> >
> > In my very humble opinion "cutting 2-0-M1" means :
> > (a) creating a 2.0 branch
> > and
> > (b) creating a 2.0-M1 tag
> >
> > All further development for 2.0 would then happen on the 2.0 branch
> instead
> > of on the trunk.
> > Isn't that the usual way to proceed ?
> >
> > Maarten
> >
> >
> >>
> >> Regards,
> >> Alan
> >>
> >>
> >
>
>
Re: [AsyncWeb] Need an async client now
Posted by Mike Heath <mh...@apache.org>.
The new logging features in SLF4J and removing IoSessionLogger were what
was holding up an M1 release. Where do we stand on the logging front
right now?
-Mike
Maarten Bosteels wrote:
> On Feb 10, 2008 9:05 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>> On Feb 10, 2008, at 11:35 AM, Maarten Bosteels wrote:
>>
>>> Hello,
>>>
>>> On Feb 10, 2008 5:28 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>
>>>> Is it ready? You're only at M1. What are the next milestones
>>>> planned
>>>> before you hit beta?
>>>
>>> The version numbering scheme is described at the bottom of
>>> http://mina.apache.org/downloads.html [1]
>>>
>>> IMO we should have created 2.0-M0 a few months ago. But for some
>>> reason we
>>> have been postponing it as long as there were open JIRA issues that
>>> could
>>> require an API change.
>>>
>>> According to [1] we are allowed to make API changes between M1 and M2
>>> but of course it's nicer for the user if we can avoid it.
>>>
>>> I just had a look at JIRA at there were more open issues than I
>>> thought (6)
>>> but no show-stoppers AFAICS.
>>>
>>> Maybe we should have a vote about cutting 2.0-M0 ?
>> Maybe I'm being dense. You mean 2.0-RC1? When do you guys cut a
>> branch to stabilize your beta? Does it depend on the situation?
>>
>
> Good question.
>
> In my very humble opinion "cutting 2-0-M1" means :
> (a) creating a 2.0 branch
> and
> (b) creating a 2.0-M1 tag
>
> All further development for 2.0 would then happen on the 2.0 branch instead
> of on the trunk.
> Isn't that the usual way to proceed ?
>
> Maarten
>
>
>>
>> Regards,
>> Alan
>>
>>
>
Re: [AsyncWeb] Need an async client now
Posted by Alex Karasulu <ak...@apache.org>.
Until 2.0 GA we should leave the trunk as is. When we go to GA after some
number of milestones then we can create the 2.0 branch which will only
include bug fixes. Right now the bleeding edge is the trunk. This is where
all new features and API changes occur.
I think we can do milestone releases while there are JIRA issues associated
with new features and API changes. Then we can announce a feature/API
freeze. We can release some GA candidates that stabilize the trunk in
preparation for the GA release: not that we're not stable but this option
exists.
Then when we all have agreed that a GA should be cut we can branch, tag and
release. The trunk becomes 2.1 or whatever we like to call it. Only bug
fixes occur on the 2.0 branch. New features and API changes go into 2.1 in
the trunk.
Does this sound reasonable?
BTW we should have cut a M1 or M0 (the first milestone release) from the
trunk a while back. I had asked when this would happen. There is no limit
to the number of milestone releases we can have. So let's pump one out. If
something pops up that presents some urgency we can release again. Let's
follow the release early, release often mantra.
Alex
On Feb 10, 2008 4:05 PM, Maarten Bosteels <mb...@gmail.com> wrote:
> On Feb 10, 2008 9:05 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> >
> > On Feb 10, 2008, at 11:35 AM, Maarten Bosteels wrote:
> >
> > > Hello,
> > >
> > > On Feb 10, 2008 5:28 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> > >
> > >> Is it ready? You're only at M1. What are the next milestones
> > >> planned
> > >> before you hit beta?
> > >
> > >
> > > The version numbering scheme is described at the bottom of
> > > http://mina.apache.org/downloads.html [1]
> > >
> > > IMO we should have created 2.0-M0 a few months ago. But for some
> > > reason we
> > > have been postponing it as long as there were open JIRA issues that
> > > could
> > > require an API change.
> > >
> > > According to [1] we are allowed to make API changes between M1 and M2
> > > but of course it's nicer for the user if we can avoid it.
> > >
> > > I just had a look at JIRA at there were more open issues than I
> > > thought (6)
> > > but no show-stoppers AFAICS.
> > >
> > > Maybe we should have a vote about cutting 2.0-M0 ?
> >
> > Maybe I'm being dense. You mean 2.0-RC1? When do you guys cut a
> > branch to stabilize your beta? Does it depend on the situation?
> >
>
> Good question.
>
> In my very humble opinion "cutting 2-0-M1" means :
> (a) creating a 2.0 branch
> and
> (b) creating a 2.0-M1 tag
>
> All further development for 2.0 would then happen on the 2.0 branch
> instead
> of on the trunk.
> Isn't that the usual way to proceed ?
>
> Maarten
>
>
> >
> >
> > Regards,
> > Alan
> >
> >
>
Re: [AsyncWeb] Need an async client now
Posted by Maarten Bosteels <mb...@gmail.com>.
On Feb 10, 2008 9:05 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> On Feb 10, 2008, at 11:35 AM, Maarten Bosteels wrote:
>
> > Hello,
> >
> > On Feb 10, 2008 5:28 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> >
> >> Is it ready? You're only at M1. What are the next milestones
> >> planned
> >> before you hit beta?
> >
> >
> > The version numbering scheme is described at the bottom of
> > http://mina.apache.org/downloads.html [1]
> >
> > IMO we should have created 2.0-M0 a few months ago. But for some
> > reason we
> > have been postponing it as long as there were open JIRA issues that
> > could
> > require an API change.
> >
> > According to [1] we are allowed to make API changes between M1 and M2
> > but of course it's nicer for the user if we can avoid it.
> >
> > I just had a look at JIRA at there were more open issues than I
> > thought (6)
> > but no show-stoppers AFAICS.
> >
> > Maybe we should have a vote about cutting 2.0-M0 ?
>
> Maybe I'm being dense. You mean 2.0-RC1? When do you guys cut a
> branch to stabilize your beta? Does it depend on the situation?
>
Good question.
In my very humble opinion "cutting 2-0-M1" means :
(a) creating a 2.0 branch
and
(b) creating a 2.0-M1 tag
All further development for 2.0 would then happen on the 2.0 branch instead
of on the trunk.
Isn't that the usual way to proceed ?
Maarten
>
>
> Regards,
> Alan
>
>
Re: [AsyncWeb] Need an async client now
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Feb 10, 2008, at 11:35 AM, Maarten Bosteels wrote:
> Hello,
>
> On Feb 10, 2008 5:28 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>> Is it ready? You're only at M1. What are the next milestones
>> planned
>> before you hit beta?
>
>
> The version numbering scheme is described at the bottom of
> http://mina.apache.org/downloads.html [1]
>
> IMO we should have created 2.0-M0 a few months ago. But for some
> reason we
> have been postponing it as long as there were open JIRA issues that
> could
> require an API change.
>
> According to [1] we are allowed to make API changes between M1 and M2
> but of course it's nicer for the user if we can avoid it.
>
> I just had a look at JIRA at there were more open issues than I
> thought (6)
> but no show-stoppers AFAICS.
>
> Maybe we should have a vote about cutting 2.0-M0 ?
Maybe I'm being dense. You mean 2.0-RC1? When do you guys cut a
branch to stabilize your beta? Does it depend on the situation?
Regards,
Alan
Re: [AsyncWeb] Need an async client now
Posted by Maarten Bosteels <mb...@gmail.com>.
Hello,
On Feb 10, 2008 5:28 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Is it ready? You're only at M1. What are the next milestones planned
> before you hit beta?
The version numbering scheme is described at the bottom of
http://mina.apache.org/downloads.html [1]
IMO we should have created 2.0-M0 a few months ago. But for some reason we
have been postponing it as long as there were open JIRA issues that could
require an API change.
According to [1] we are allowed to make API changes between M1 and M2
but of course it's nicer for the user if we can avoid it.
I just had a look at JIRA at there were more open issues than I thought (6)
but no show-stoppers AFAICS.
Maybe we should have a vote about cutting 2.0-M0 ?
Maarten
>
>
> Regards,
> Alan
>
> On Feb 9, 2008, at 3:56 PM, Maarten Bosteels wrote:
>
> >> Sticking to MINA 2.0 overall will be in the best interest of the
> >> community
> >
> > I couldn't agree more. I really see no reason to stick with 1.x
> > In fact, I think we should 'release' MINA-2.0-M1 asap.
> >
> > Maarten
> >
> > On Feb 9, 2008 7:49 PM, Alex Karasulu <ak...@apache.org> wrote:
> >
> >> On Feb 9, 2008 12:39 PM, Alan D. Cabrera <li...@toolazydogs.com>
> >> wrote:
> >>
> >>>
> >>> On Feb 9, 2008, at 6:09 AM, Alex Karasulu wrote:
> >>>
> >>>> On Feb 9, 2008 3:56 AM, Alan D. Cabrera <li...@toolazydogs.com>
> >>>> wrote:
> >>>>
> >>>>> What should I use? I prefer the API from Geronimo but I see
> >>>>> that it
> >>>>> doesn't get built in in Mina. I would also prefer to use Mina 1.x
> >>>>> and
> >>>>> wait until Mina 2.x shakes itself out.
> >>>>>
> >>>>> So, I'm going to toss out the idea of releasing the new API as 1.0
> >>>>> and
> >>>>> we can release the new Mina 2.x based API as 2.0. Thoughts?
> >>>>>
> >>>>
> >>>> IMO I think looking ahead towards the use of MINA 2.0 is the best
> >>>> route here
> >>>> and it seems that people have already taken care of the merge.
> >>>> Perhaps
> >>>> there's some emails that you may have missed on the commits@ list
> >>>> and here.
> >>>> Mike already merged the two I think unless I'm mistaken which may
> >>>> be
> >>>> the
> >>>> case since I have been catching up as well.
> >>>
> >>> Well, it is in SVN. At the moment there are two clients in there.
> >>> The newer one does not get added to the Jar artifact per its POM
> >>> configuration. I really prefer the newer one from Geronimo.
> >>>
> >>>> Oh and 1.0 whichever MINA it's based on makes sense to me but
> >>>> jumping
> >>>> to 2.0 to denote the use of MINA
> >>>> 2.0 sounds good too. I just think we should stick to MINA 2.0
> >>>> through and
> >>>> through because of the gains made therein.
> >>>
> >>> Only the Pope and my mother-in-law are infallible. I think that
> >>> MINA
> >>> 2.x rocks and will be a resounding success but I think it will
> >>> take a
> >>> little bit for things to shake out. IIUC, there's still
> >>> discussion to
> >>> fiddle with bits of 2.0.
> >>>
> >>> I just want to start w/ MINA 1.x for now. Its characteristics are
> >>> known and it's been around the block a few times. I am happy to do
> >>> the scut work for a 1.0 release.
> >>>
> >>
> >> Loved the comment about the Pope and your MIL :). You can always
> >> work on
> >> a
> >> 1.0 based version but we're still far from a release as well since
> >> the PMC
> >> is just mobilizing around these new projects. Also note that a MINA
> >> 2.0release is imminent. Furthermore there's been considerable effort
> >> put into
> >> keeping all the people interested in Asyncweb working together
> >> towards a
> >> common goal. Sticking to MINA 2.0 overall will be in the best
> >> interest of
> >> the community. We're seeing great synergy where core MINA folks are
> >> working
> >> closely with the AHC developers. It's really great to see ramping
> >> up and
> >> took a bit of effort.
> >>
> >> If there are any hick-ups along the way with MINA 2.0 you have my
> >> word and
> >> I'm sure the word of others' here to resolve them immediately.
> >> Fragmenting
> >> this community into those that work on 1.0 and 2.0 based version of
> >> AHC
> >> just
> >> when the collaboration is ramping up would not be good. Please don't
> >> presume the time frame is going to be longer when based on MINA 2.0.
> >> Whatever the issue may be for you we'll try our best to accommodate
> >> whatever
> >> it may be. Is there some other problem that you have not mentioned
> >> which
> >> requires a 1.0 release besides just doing it rapidly?
> >>
> >> Thanks,
> >> Alex
> >>
>
>
Re: [AsyncWeb] Need an async client now
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Is it ready? You're only at M1. What are the next milestones planned
before you hit beta?
Regards,
Alan
On Feb 9, 2008, at 3:56 PM, Maarten Bosteels wrote:
>> Sticking to MINA 2.0 overall will be in the best interest of the
>> community
>
> I couldn't agree more. I really see no reason to stick with 1.x
> In fact, I think we should 'release' MINA-2.0-M1 asap.
>
> Maarten
>
> On Feb 9, 2008 7:49 PM, Alex Karasulu <ak...@apache.org> wrote:
>
>> On Feb 9, 2008 12:39 PM, Alan D. Cabrera <li...@toolazydogs.com>
>> wrote:
>>
>>>
>>> On Feb 9, 2008, at 6:09 AM, Alex Karasulu wrote:
>>>
>>>> On Feb 9, 2008 3:56 AM, Alan D. Cabrera <li...@toolazydogs.com>
>>>> wrote:
>>>>
>>>>> What should I use? I prefer the API from Geronimo but I see
>>>>> that it
>>>>> doesn't get built in in Mina. I would also prefer to use Mina 1.x
>>>>> and
>>>>> wait until Mina 2.x shakes itself out.
>>>>>
>>>>> So, I'm going to toss out the idea of releasing the new API as 1.0
>>>>> and
>>>>> we can release the new Mina 2.x based API as 2.0. Thoughts?
>>>>>
>>>>
>>>> IMO I think looking ahead towards the use of MINA 2.0 is the best
>>>> route here
>>>> and it seems that people have already taken care of the merge.
>>>> Perhaps
>>>> there's some emails that you may have missed on the commits@ list
>>>> and here.
>>>> Mike already merged the two I think unless I'm mistaken which may
>>>> be
>>>> the
>>>> case since I have been catching up as well.
>>>
>>> Well, it is in SVN. At the moment there are two clients in there.
>>> The newer one does not get added to the Jar artifact per its POM
>>> configuration. I really prefer the newer one from Geronimo.
>>>
>>>> Oh and 1.0 whichever MINA it's based on makes sense to me but
>>>> jumping
>>>> to 2.0 to denote the use of MINA
>>>> 2.0 sounds good too. I just think we should stick to MINA 2.0
>>>> through and
>>>> through because of the gains made therein.
>>>
>>> Only the Pope and my mother-in-law are infallible. I think that
>>> MINA
>>> 2.x rocks and will be a resounding success but I think it will
>>> take a
>>> little bit for things to shake out. IIUC, there's still
>>> discussion to
>>> fiddle with bits of 2.0.
>>>
>>> I just want to start w/ MINA 1.x for now. Its characteristics are
>>> known and it's been around the block a few times. I am happy to do
>>> the scut work for a 1.0 release.
>>>
>>
>> Loved the comment about the Pope and your MIL :). You can always
>> work on
>> a
>> 1.0 based version but we're still far from a release as well since
>> the PMC
>> is just mobilizing around these new projects. Also note that a MINA
>> 2.0release is imminent. Furthermore there's been considerable effort
>> put into
>> keeping all the people interested in Asyncweb working together
>> towards a
>> common goal. Sticking to MINA 2.0 overall will be in the best
>> interest of
>> the community. We're seeing great synergy where core MINA folks are
>> working
>> closely with the AHC developers. It's really great to see ramping
>> up and
>> took a bit of effort.
>>
>> If there are any hick-ups along the way with MINA 2.0 you have my
>> word and
>> I'm sure the word of others' here to resolve them immediately.
>> Fragmenting
>> this community into those that work on 1.0 and 2.0 based version of
>> AHC
>> just
>> when the collaboration is ramping up would not be good. Please don't
>> presume the time frame is going to be longer when based on MINA 2.0.
>> Whatever the issue may be for you we'll try our best to accommodate
>> whatever
>> it may be. Is there some other problem that you have not mentioned
>> which
>> requires a 1.0 release besides just doing it rapidly?
>>
>> Thanks,
>> Alex
>>
Re: [AsyncWeb] Need an async client now
Posted by "이희승 (Trustin Lee)" <tr...@gmail.com>.
2008-02-10 (일), 00:56 +0100, Maarten Bosteels 쓰시길:
> > Sticking to MINA 2.0 overall will be in the best interest of the community
>
> I couldn't agree more. I really see no reason to stick with 1.x
> In fact, I think we should 'release' MINA-2.0-M1 asap.
Yeah, go MINA! :)
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [AsyncWeb] Need an async client now
Posted by Maarten Bosteels <mb...@gmail.com>.
> Sticking to MINA 2.0 overall will be in the best interest of the community
I couldn't agree more. I really see no reason to stick with 1.x
In fact, I think we should 'release' MINA-2.0-M1 asap.
Maarten
On Feb 9, 2008 7:49 PM, Alex Karasulu <ak...@apache.org> wrote:
> On Feb 9, 2008 12:39 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> >
> > On Feb 9, 2008, at 6:09 AM, Alex Karasulu wrote:
> >
> > > On Feb 9, 2008 3:56 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> > >
> > >> What should I use? I prefer the API from Geronimo but I see that it
> > >> doesn't get built in in Mina. I would also prefer to use Mina 1.x
> > >> and
> > >> wait until Mina 2.x shakes itself out.
> > >>
> > >> So, I'm going to toss out the idea of releasing the new API as 1.0
> > >> and
> > >> we can release the new Mina 2.x based API as 2.0. Thoughts?
> > >>
> > >
> > > IMO I think looking ahead towards the use of MINA 2.0 is the best
> > > route here
> > > and it seems that people have already taken care of the merge.
> > > Perhaps
> > > there's some emails that you may have missed on the commits@ list
> > > and here.
> > > Mike already merged the two I think unless I'm mistaken which may be
> > > the
> > > case since I have been catching up as well.
> >
> > Well, it is in SVN. At the moment there are two clients in there.
> > The newer one does not get added to the Jar artifact per its POM
> > configuration. I really prefer the newer one from Geronimo.
> >
> > > Oh and 1.0 whichever MINA it's based on makes sense to me but jumping
> > > to 2.0 to denote the use of MINA
> > > 2.0 sounds good too. I just think we should stick to MINA 2.0
> > > through and
> > > through because of the gains made therein.
> >
> > Only the Pope and my mother-in-law are infallible. I think that MINA
> > 2.x rocks and will be a resounding success but I think it will take a
> > little bit for things to shake out. IIUC, there's still discussion to
> > fiddle with bits of 2.0.
> >
> > I just want to start w/ MINA 1.x for now. Its characteristics are
> > known and it's been around the block a few times. I am happy to do
> > the scut work for a 1.0 release.
> >
>
> Loved the comment about the Pope and your MIL :). You can always work on
> a
> 1.0 based version but we're still far from a release as well since the PMC
> is just mobilizing around these new projects. Also note that a MINA
> 2.0release is imminent. Furthermore there's been considerable effort
> put into
> keeping all the people interested in Asyncweb working together towards a
> common goal. Sticking to MINA 2.0 overall will be in the best interest of
> the community. We're seeing great synergy where core MINA folks are
> working
> closely with the AHC developers. It's really great to see ramping up and
> took a bit of effort.
>
> If there are any hick-ups along the way with MINA 2.0 you have my word and
> I'm sure the word of others' here to resolve them immediately.
> Fragmenting
> this community into those that work on 1.0 and 2.0 based version of AHC
> just
> when the collaboration is ramping up would not be good. Please don't
> presume the time frame is going to be longer when based on MINA 2.0.
> Whatever the issue may be for you we'll try our best to accommodate
> whatever
> it may be. Is there some other problem that you have not mentioned which
> requires a 1.0 release besides just doing it rapidly?
>
> Thanks,
> Alex
>
Re: [AsyncWeb] Need an async client now
Posted by Alex Karasulu <ak...@apache.org>.
On Feb 9, 2008 12:39 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> On Feb 9, 2008, at 6:09 AM, Alex Karasulu wrote:
>
> > On Feb 9, 2008 3:56 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> >
> >> What should I use? I prefer the API from Geronimo but I see that it
> >> doesn't get built in in Mina. I would also prefer to use Mina 1.x
> >> and
> >> wait until Mina 2.x shakes itself out.
> >>
> >> So, I'm going to toss out the idea of releasing the new API as 1.0
> >> and
> >> we can release the new Mina 2.x based API as 2.0. Thoughts?
> >>
> >
> > IMO I think looking ahead towards the use of MINA 2.0 is the best
> > route here
> > and it seems that people have already taken care of the merge.
> > Perhaps
> > there's some emails that you may have missed on the commits@ list
> > and here.
> > Mike already merged the two I think unless I'm mistaken which may be
> > the
> > case since I have been catching up as well.
>
> Well, it is in SVN. At the moment there are two clients in there.
> The newer one does not get added to the Jar artifact per its POM
> configuration. I really prefer the newer one from Geronimo.
>
> > Oh and 1.0 whichever MINA it's based on makes sense to me but jumping
> > to 2.0 to denote the use of MINA
> > 2.0 sounds good too. I just think we should stick to MINA 2.0
> > through and
> > through because of the gains made therein.
>
> Only the Pope and my mother-in-law are infallible. I think that MINA
> 2.x rocks and will be a resounding success but I think it will take a
> little bit for things to shake out. IIUC, there's still discussion to
> fiddle with bits of 2.0.
>
> I just want to start w/ MINA 1.x for now. Its characteristics are
> known and it's been around the block a few times. I am happy to do
> the scut work for a 1.0 release.
>
Loved the comment about the Pope and your MIL :). You can always work on a
1.0 based version but we're still far from a release as well since the PMC
is just mobilizing around these new projects. Also note that a MINA
2.0release is imminent. Furthermore there's been considerable effort
put into
keeping all the people interested in Asyncweb working together towards a
common goal. Sticking to MINA 2.0 overall will be in the best interest of
the community. We're seeing great synergy where core MINA folks are working
closely with the AHC developers. It's really great to see ramping up and
took a bit of effort.
If there are any hick-ups along the way with MINA 2.0 you have my word and
I'm sure the word of others' here to resolve them immediately. Fragmenting
this community into those that work on 1.0 and 2.0 based version of AHC just
when the collaboration is ramping up would not be good. Please don't
presume the time frame is going to be longer when based on MINA 2.0.
Whatever the issue may be for you we'll try our best to accommodate whatever
it may be. Is there some other problem that you have not mentioned which
requires a 1.0 release besides just doing it rapidly?
Thanks,
Alex
Re: [AsyncWeb] Need an async client now
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Feb 9, 2008, at 6:09 AM, Alex Karasulu wrote:
> On Feb 9, 2008 3:56 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>> What should I use? I prefer the API from Geronimo but I see that it
>> doesn't get built in in Mina. I would also prefer to use Mina 1.x
>> and
>> wait until Mina 2.x shakes itself out.
>>
>> So, I'm going to toss out the idea of releasing the new API as 1.0
>> and
>> we can release the new Mina 2.x based API as 2.0. Thoughts?
>>
>
> IMO I think looking ahead towards the use of MINA 2.0 is the best
> route here
> and it seems that people have already taken care of the merge.
> Perhaps
> there's some emails that you may have missed on the commits@ list
> and here.
> Mike already merged the two I think unless I'm mistaken which may be
> the
> case since I have been catching up as well.
Well, it is in SVN. At the moment there are two clients in there.
The newer one does not get added to the Jar artifact per its POM
configuration. I really prefer the newer one from Geronimo.
> Oh and 1.0 whichever MINA it's based on makes sense to me but jumping
> to 2.0 to denote the use of MINA
> 2.0 sounds good too. I just think we should stick to MINA 2.0
> through and
> through because of the gains made therein.
Only the Pope and my mother-in-law are infallible. I think that MINA
2.x rocks and will be a resounding success but I think it will take a
little bit for things to shake out. IIUC, there's still discussion to
fiddle with bits of 2.0.
I just want to start w/ MINA 1.x for now. Its characteristics are
known and it's been around the block a few times. I am happy to do
the scut work for a 1.0 release.
Regards,
Alan
Re: [AsyncWeb] Need an async client now
Posted by Alex Karasulu <ak...@apache.org>.
Hi Alan,
Great to see you here btw. When Alan is interested in a project that only
means it's going places :).
On Feb 9, 2008 3:56 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> What should I use? I prefer the API from Geronimo but I see that it
> doesn't get built in in Mina. I would also prefer to use Mina 1.x and
> wait until Mina 2.x shakes itself out.
>
> So, I'm going to toss out the idea of releasing the new API as 1.0 and
> we can release the new Mina 2.x based API as 2.0. Thoughts?
>
IMO I think looking ahead towards the use of MINA 2.0 is the best route here
and it seems that people have already taken care of the merge. Perhaps
there's some emails that you may have missed on the commits@ list and here.
Mike already merged the two I think unless I'm mistaken which may be the
case since I have been catching up as well.
Oh and 1.0 whichever MINA it's based on makes sense to me but jumping
to 2.0to denote the use of MINA
2.0 sounds good too. I just think we should stick to MINA 2.0 through and
through because of the gains made therein.
Regards,
Alex