You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Craig L. Ching" <cc...@mqsoftware.com> on 2008/06/05 17:23:33 UTC
Current state of 2.0
Hi all,
I've been sort of following some of the discussions of the proposed
changes and I like what I'm hearing. In fact, I'd love it if someone
could say how soon I could expect to see a release of all the good ideas
;-)
Anyway, I'm coming back to a project that I had originally working with
1.1.6 and had converted to 2.0 M1, but found a problem with that that
was promptly fixed on trunk at the time, around 17 March, 2008. My code
worked with trunk then and what I'm wondering is what the chances are
that it will still work? Have any of the big changes you've all been
talking about been put on the trunk yet? I appreciate any feedback, I
know you're all busy, and if I don't hear anything, I'll just give it my
best shot, but I do appreciate any information I can get.
Cheers,
Craig
Re: Current state of 2.0
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Wed, Jun 11, 2008 at 5:43 PM, peter royal <pe...@pobox.com> wrote:
> On Jun 6, 2008, at 8:31 AM, Craig L. Ching wrote:
> The fundamental changes to the IoBuffer API very likely won't happen for
> 2.0, since 2.0 is close to being complete.
>
> At this stage, I think the best approach will be for the community to get
> 2.0 out the door, and then we can look at more radical API changes for 3.0..
I agree, I think we should focus on stabilizing 2.0 rather than making
substantial changes at this moment.
/niklas
Re: Current state of 2.0
Posted by Emmanuel Lecharny <el...@apache.org>.
Brian McCallister wrote:
> Frequent (one a year is very very frequent) backwards incompatible API
> changes lead to no users. If ya'll take this roadmap I, for one, will go
> find some library which isn't going to dead end me in the *foreseeable*
> future.
>
This is something we have to consider, that's for sure. And this was
also something we already said in one of the previous thread, which led
to a differed release for 2.0.
But we can certainly discuss it further. Right now, as stated correctly
by Nicklas, focusing on stabilizing and documenting the trunk may be our
first target... Seems like many of us is working on adding documentation
to the code, which is good.
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Current state of 2.0
Posted by Emmanuel Lecharny <el...@apache.org>.
Alex Karasulu wrote:
> +1 with pushing in all the API changes we will need for a long long time to
> come.
>
> Make the users happy. That means taking a little longer with 2.0 GA but
> probably not that much longer and we're close as Nicklas says. Let's go for
> all the good stuff as discussed in the BB threads and get this wrapped up.
>
+1. It may take 3 months, but it worths the effort, since it will be
good for the next 5 years !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Current state of 2.0
Posted by Alex Karasulu <ak...@apache.org>.
+1 with pushing in all the API changes we will need for a long long time to
come.
Make the users happy. That means taking a little longer with 2.0 GA but
probably not that much longer and we're close as Nicklas says. Let's go for
all the good stuff as discussed in the BB threads and get this wrapped up.
Alex
On Wed, Jun 11, 2008 at 3:13 PM, Niklas Gustavsson <ni...@protocol7.com>
wrote:
> On Wed, Jun 11, 2008 at 8:59 PM, Brian McCallister <br...@skife.org>
> wrote:
> > Get the 2.0 API to the one you want to use for the next five years and
> then
> > use it for the next five years.
>
> I agree, and for me we are there already.
>
> /niklas
>
Re: Current state of 2.0
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Wed, Jun 11, 2008 at 8:59 PM, Brian McCallister <br...@skife.org> wrote:
> Get the 2.0 API to the one you want to use for the next five years and then
> use it for the next five years.
I agree, and for me we are there already.
/niklas
Re: Current state of 2.0
Posted by Brian McCallister <br...@skife.org>.
On Wed, Jun 11, 2008 at 10:37 AM, peter royal <pe...@pobox.com> wrote:
> On Jun 11, 2008, at 10:26 AM, Brian McCallister wrote:
>
>> Frequent (one a year is very very frequent) backwards incompatible API
>> changes lead to no users. If ya'll take this roadmap I, for one, will go
>> find some library which isn't going to dead end me in the *foreseeable*
>> future.
>>
>
> agreed 100%
>
> i still have some code on MINA v1 due to the vast number of changes that
> have happened to the API with v2
>
> based on what Emmanuel laid out, the only backwards incompatible change is
> a new ByteBuffer implementation. I don't believe NIO.2 should involve any
> radical API changes for users, as it would just optimize MINA internals.
>
> with that said, would you prefer a continuing of changes now for v2 to
> provide a stable API looking far in the future (the ByteBuffer changes) ?
>
> the struggle i have is at what point do we say "the v2 API is sealed, lets
> release it", vs "there's a ton of changes in v2 already, lets get the rest
> of the incompatible ones we see done so we don't have to do it again"
>
> thoughts?
Get the 2.0 API to the one you want to use for the next five years and then
use it for the next five years.
-Brian
>
>
> -pete
>
> --
> (peter.royal|osi)@pobox.com - http://fotap.org/~osi<http://fotap.org/%7Eosi>
>
>
Re: Current state of 2.0
Posted by peter royal <pe...@pobox.com>.
On Jun 11, 2008, at 10:26 AM, Brian McCallister wrote:
> Frequent (one a year is very very frequent) backwards incompatible API
> changes lead to no users. If ya'll take this roadmap I, for one,
> will go
> find some library which isn't going to dead end me in the
> *foreseeable*
> future.
agreed 100%
i still have some code on MINA v1 due to the vast number of changes
that have happened to the API with v2
based on what Emmanuel laid out, the only backwards incompatible
change is a new ByteBuffer implementation. I don't believe NIO.2
should involve any radical API changes for users, as it would just
optimize MINA internals.
with that said, would you prefer a continuing of changes now for v2 to
provide a stable API looking far in the future (the ByteBuffer
changes) ?
the struggle i have is at what point do we say "the v2 API is sealed,
lets release it", vs "there's a ton of changes in v2 already, lets get
the rest of the incompatible ones we see done so we don't have to do
it again"
thoughts?
-pete
--
(peter.royal|osi)@pobox.com - http://fotap.org/~osi
Re: Current state of 2.0
Posted by Brian McCallister <br...@skife.org>.
Frequent (one a year is very very frequent) backwards incompatible API
changes lead to no users. If ya'll take this roadmap I, for one, will go
find some library which isn't going to dead end me in the *foreseeable*
future.
-Brian
On Wed, Jun 11, 2008 at 10:09 AM, Emmanuel Lecharny <el...@apache.org>
wrote:
> peter royal wrote:
>
>> On Jun 11, 2008, at 9:07 AM, Emmanuel Lecharny wrote:
>>
>>> we have discussed both options a month ago, and there were quite a
>>> concensus to get these changes into a postponed 2.0, instead of delivering a
>>> 2.0 and including changes into a 3.0.
>>>
>>> Now the environment has changed a bit in the last few weeks, and we have
>>> a lot of thing to do in order to get a 2.0 out, even if we don't include the
>>> ByteBuffer rewrite.
>>>
>>> IMHO, we can go for a documented 2.0 for the moment (and it will take a
>>> while), and start a branch for 3.0.
>>>
>>
>> whoops! silly me for missing that :) must have been buried in a thread i
>> glazed over :)
>>
>> anyways, yes, i agree with a documented and cleaned up 2.0, with more
>> substantial changes in a separate branch for the time being. we've been
>> promising 2.0 for a LOOONG time, so i think we owe it to the community to
>> deliver upon that.
>>
>> -pete
>>
> I have also started a thread about NIO 2.0 (expected soon for Java 7), I
> was wondering if we can't define a long term roadmap where, for instance :
> 2.0 : expected by Q3/Q4 2008, with the current trunk content, documented
> and decyphered,
> 3.0 : somewhere in 2009, with the new ByteBuffer implementation (and other
> things to be defined)
> 4.0 : Support for NIO 2.0 (or may be another name like MINA2, I don't
> know). Not that Java 7 is widely used right now, I don't even think that
> more than 50% of the Java users have switched to Java 6 yet, but it's good
> to give ome visibility to our users ...
>
> wdyt ?
>
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: Current state of 2.0
Posted by Emmanuel Lecharny <el...@apache.org>.
peter royal wrote:
> On Jun 11, 2008, at 9:07 AM, Emmanuel Lecharny wrote:
>> we have discussed both options a month ago, and there were quite a
>> concensus to get these changes into a postponed 2.0, instead of
>> delivering a 2.0 and including changes into a 3.0.
>>
>> Now the environment has changed a bit in the last few weeks, and we
>> have a lot of thing to do in order to get a 2.0 out, even if we don't
>> include the ByteBuffer rewrite.
>>
>> IMHO, we can go for a documented 2.0 for the moment (and it will take
>> a while), and start a branch for 3.0.
>
> whoops! silly me for missing that :) must have been buried in a thread
> i glazed over :)
>
> anyways, yes, i agree with a documented and cleaned up 2.0, with more
> substantial changes in a separate branch for the time being. we've
> been promising 2.0 for a LOOONG time, so i think we owe it to the
> community to deliver upon that.
>
> -pete
I have also started a thread about NIO 2.0 (expected soon for Java 7), I
was wondering if we can't define a long term roadmap where, for instance :
2.0 : expected by Q3/Q4 2008, with the current trunk content, documented
and decyphered,
3.0 : somewhere in 2009, with the new ByteBuffer implementation (and
other things to be defined)
4.0 : Support for NIO 2.0 (or may be another name like MINA2, I don't
know). Not that Java 7 is widely used right now, I don't even think that
more than 50% of the Java users have switched to Java 6 yet, but it's
good to give ome visibility to our users ...
wdyt ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Current state of 2.0
Posted by peter royal <pe...@pobox.com>.
On Jun 11, 2008, at 9:07 AM, Emmanuel Lecharny wrote:
> we have discussed both options a month ago, and there were quite a
> concensus to get these changes into a postponed 2.0, instead of
> delivering a 2.0 and including changes into a 3.0.
>
> Now the environment has changed a bit in the last few weeks, and we
> have a lot of thing to do in order to get a 2.0 out, even if we
> don't include the ByteBuffer rewrite.
>
> IMHO, we can go for a documented 2.0 for the moment (and it will
> take a while), and start a branch for 3.0.
whoops! silly me for missing that :) must have been buried in a thread
i glazed over :)
anyways, yes, i agree with a documented and cleaned up 2.0, with more
substantial changes in a separate branch for the time being. we've
been promising 2.0 for a LOOONG time, so i think we owe it to the
community to deliver upon that.
-pete
--
(peter.royal|osi)@pobox.com - http://fotap.org/~osi
Re: Current state of 2.0
Posted by Emmanuel Lecharny <el...@apache.org>.
peter royal wrote:
> On Jun 6, 2008, at 8:31 AM, Craig L. Ching wrote:
>> Yeah, I'm just wondering if there have been any commits yet that have
>> fundamentally changed the API's (ByteBuffer in particular) that might
>> "get" me if you know what I mean. I'm fine with the changes I'm
>> hearing, don't get me wrong, I'm just trying to quantify (very
>> loosely speaking) the work I'll have to do when I do an svn update
>> and build ;-) Thanks for the reply!
>
> The fundamental changes to the IoBuffer API very likely won't happen
> for 2.0, since 2.0 is close to being complete.
>
> At this stage, I think the best approach will be for the community to
> get 2.0 out the door, and then we can look at more radical API changes
> for 3.0..
>
> -pete
>
Hi Peter,
we have discussed both options a month ago, and there were quite a
concensus to get these changes into a postponed 2.0, instead of
delivering a 2.0 and including changes into a 3.0.
Now the environment has changed a bit in the last few weeks, and we have
a lot of thing to do in order to get a 2.0 out, even if we don't include
the ByteBuffer rewrite.
IMHO, we can go for a documented 2.0 for the moment (and it will take a
while), and start a branch for 3.0.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Current state of 2.0
Posted by peter royal <pe...@pobox.com>.
On Jun 6, 2008, at 8:31 AM, Craig L. Ching wrote:
> Yeah, I'm just wondering if there have been any commits yet that
> have fundamentally changed the API's (ByteBuffer in particular) that
> might "get" me if you know what I mean. I'm fine with the changes
> I'm hearing, don't get me wrong, I'm just trying to quantify (very
> loosely speaking) the work I'll have to do when I do an svn update
> and build ;-) Thanks for the reply!
The fundamental changes to the IoBuffer API very likely won't happen
for 2.0, since 2.0 is close to being complete.
At this stage, I think the best approach will be for the community to
get 2.0 out the door, and then we can look at more radical API changes
for 3.0..
-pete
--
(peter.royal|osi)@pobox.com - http://fotap.org/~osi
RE: Current state of 2.0
Posted by "Craig L. Ching" <cc...@mqsoftware.com>.
Sorry, but I said ByteBuffer, I mean IoBuffer.
> -----Original Message-----
> From: Craig L. Ching [mailto:cching@mqsoftware.com]
> Sent: Friday, June 06, 2008 10:32 AM
> To: dev@mina.apache.org; elecharny@apache.org
> Subject: RE: Current state of 2.0
>
>
>
> > -----Original Message-----
> > From: Emmanuel Lecharny [mailto:elecharny@gmail.com] On Behalf Of
> > Emmanuel Lecharny
> > Sent: Friday, June 06, 2008 10:23 AM
> > To: dev@mina.apache.org
> > Subject: Re: Current state of 2.0
> >
> > Craig L. Ching wrote:
> > > Hi all,
> > >
> > Hi Craig,
> > > I've been sort of following some of the discussions of
> the proposed
> > > changes and I like what I'm hearing. In fact, I'd love it
> > if someone
> > > could say how soon I could expect to see a release of all
> the good
> > > ideas
> > > ;-)
> > >
> > Well, soon ... :) We don't have any deadline, we are just
> processing
> > tasks as fast as we can.
> >
> > However, as it's a volunteer effort, we have a limited
> time, but the
> > good point is that we welcome any help !
> >
> > So if you feel like you can give us a hand to deliver 2.0
> earlier, you
> > are very welcome :)
>
> Of course ;-) I'll probably be more involved in testing it
> once it's ready though :-P
>
> > > Anyway, I'm coming back to a project that I had
> originally working
> > > with
> > > 1.1.6 and had converted to 2.0 M1, but found a problem with
> > that that
> > > was promptly fixed on trunk at the time, around 17 March,
> 2008. My
> > > code worked with trunk then and what I'm wondering is what
> > the chances
> > > are that it will still work? Have any of the big changes
> > you've all
> > > been talking about been put on the trunk yet? I appreciate any
> > > feedback, I know you're all busy, and if I don't hear
> > anything, I'll
> > > just give it my best shot, but I do appreciate any
> > information I can get.
> > >
> > 2.0-M1 is just a milestone. Things can change before we get to
> > 2.0-RC1, which will see the API frozen. Until then, it's
> really likely
> > that some refactoring could occur. So keep watching :)
> >
>
> Yeah, I'm just wondering if there have been any commits yet
> that have fundamentally changed the API's (ByteBuffer in
> particular) that might "get" me if you know what I mean. I'm
> fine with the changes I'm hearing, don't get me wrong, I'm
> just trying to quantify (very loosely speaking) the work I'll
> have to do when I do an svn update and build ;-) Thanks for
> the reply!
>
> > Thanks !
> >
> >
> > --
> > --
> > cordialement, regards,
> > Emmanuel Lécharny
> > www.iktek.com
> > directory.apache.org
> >
> >
> >
> Cheers,
> Craig
>
RE: Current state of 2.0
Posted by "Craig L. Ching" <cc...@mqsoftware.com>.
> -----Original Message-----
> From: Emmanuel Lecharny [mailto:elecharny@gmail.com] On
> Behalf Of Emmanuel Lecharny
> Sent: Friday, June 06, 2008 10:23 AM
> To: dev@mina.apache.org
> Subject: Re: Current state of 2.0
>
> Craig L. Ching wrote:
> > Hi all,
> >
> Hi Craig,
> > I've been sort of following some of the discussions of the proposed
> > changes and I like what I'm hearing. In fact, I'd love it
> if someone
> > could say how soon I could expect to see a release of all the good
> > ideas
> > ;-)
> >
> Well, soon ... :) We don't have any deadline, we are just
> processing tasks as fast as we can.
>
> However, as it's a volunteer effort, we have a limited time,
> but the good point is that we welcome any help !
>
> So if you feel like you can give us a hand to deliver 2.0
> earlier, you are very welcome :)
Of course ;-) I'll probably be more involved in testing it once it's ready though :-P
> > Anyway, I'm coming back to a project that I had originally working
> > with
> > 1.1.6 and had converted to 2.0 M1, but found a problem with
> that that
> > was promptly fixed on trunk at the time, around 17 March, 2008. My
> > code worked with trunk then and what I'm wondering is what
> the chances
> > are that it will still work? Have any of the big changes
> you've all
> > been talking about been put on the trunk yet? I appreciate any
> > feedback, I know you're all busy, and if I don't hear
> anything, I'll
> > just give it my best shot, but I do appreciate any
> information I can get.
> >
> 2.0-M1 is just a milestone. Things can change before we get
> to 2.0-RC1, which will see the API frozen. Until then, it's
> really likely that some refactoring could occur. So keep watching :)
>
Yeah, I'm just wondering if there have been any commits yet that have fundamentally changed the API's (ByteBuffer in particular) that might "get" me if you know what I mean. I'm fine with the changes I'm hearing, don't get me wrong, I'm just trying to quantify (very loosely speaking) the work I'll have to do when I do an svn update and build ;-) Thanks for the reply!
> Thanks !
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Cheers,
Craig
Re: Current state of 2.0
Posted by Emmanuel Lecharny <el...@apache.org>.
Craig L. Ching wrote:
> Hi all,
>
Hi Craig,
> I've been sort of following some of the discussions of the proposed
> changes and I like what I'm hearing. In fact, I'd love it if someone
> could say how soon I could expect to see a release of all the good ideas
> ;-)
>
Well, soon ... :) We don't have any deadline, we are just processing
tasks as fast as we can.
However, as it's a volunteer effort, we have a limited time, but the
good point is that we welcome any help !
So if you feel like you can give us a hand to deliver 2.0 earlier, you
are very welcome :)
> Anyway, I'm coming back to a project that I had originally working with
> 1.1.6 and had converted to 2.0 M1, but found a problem with that that
> was promptly fixed on trunk at the time, around 17 March, 2008. My code
> worked with trunk then and what I'm wondering is what the chances are
> that it will still work? Have any of the big changes you've all been
> talking about been put on the trunk yet? I appreciate any feedback, I
> know you're all busy, and if I don't hear anything, I'll just give it my
> best shot, but I do appreciate any information I can get.
>
2.0-M1 is just a milestone. Things can change before we get to 2.0-RC1,
which will see the API frozen. Until then, it's really likely that some
refactoring could occur. So keep watching :)
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org