Re: Re: Fwd: [Dev] OSCON Slides

[Rob Butler <cr...@yahoo.com>]

Hi Trustin,

Thanks for the info.  I've actually been hanging out
on the Mina list for a while and even submitted the
UDP configuration bug that you fixed for 0.9.5.  I
plan on implementing a couple of different types of
servers on top of Mina's core, so the work you guys
are doing is pretty important to me.

I cc'd this message to the mina list as most of these
questions are mina specific.  Anyone who want's to
catch up on the thread can view the original posts
here
http://www.safehaus.org/pipermail/dev/2006-September/000884.html

I pretty much agree with all the comments you made,
except the one below struck me as kind of odd.
 
> > >*) AsyncWeb uses the older concurrent library
> > > instead
> > > >of Java 1.5's library.  Of course, if you want
> to
> > > run
> > > >on 1.4 still this wouldn't be possible.  Have
> you
> > > >considered making 1.5 a requirement?
> 
> Dave is leading the project, so I don't know what
> exactly his plan is, but I
> think aigning the overall plan with MINA would be
> nice.  MINA currently runs
> with JAva 1.4 and we will maintain this
> compatibility in MINA 1.0.  We will
> aggresively utilize Java 5 constructs from 1.1.  So
> AsyncWeb will also
> benefit from all the changes made from 1.1.  Vinod
> Panicker told me that
> changing MINA's internal thread pool implementation
> to use Java 5 concurrent
> utilities improves performance dramatically.

Why stay with 1.4 compatibility for Mina 1.0 when you
plan on going to 1.5 almost immediately?  Is it just
to get a "1.0" released relatively soon?  Is it
because ApacheDS has a dependency on Mina and couldn't
re-fit to Java 1.5?

The reasons I feel staying with 1.4 is odd if you plan
on going to 1.5 for Mina 1.1 are:

*) Users of Mina 1.0 will have to upgrade to Java 1.5
when they want to use the next version of Mina.  This
will likely be a fairly drastic change similar to the
changes between 0.8.0 and 0.9.5.  Why put your users
through this pain?

*) 1.5 offers a good speed improvement and has been
out a long time now.  Most Mina projects (with the
exception of AsyncWeb and ApacheDS) will probably be
new development.  I would expect anyone starting a new
project to use 1.5 and not be stuck with 1.4. 
Sticking with 1.4 compatibility in Mina impedes
projects starting to use Mina from taking full
advantage of 1.5.

When do you expect Mina to release 1.0 final?  Taking
a look at Jira I see only 4 issues in the 0.95 or 1.0
versions.  Personally I think the JMX integration
(DIRMINA-29) could take a back seat until after 1.0 is
released.  Hopefully the other 3 could be buttoned up
quickly.  If you intend to address a significant
number of the unscheduled issues before 1.0 it's going
to be some time before 1.0 can be released.  That
would make moving to Java 1.5 sooner even more
important.  Heck, Java 1.6 is just around the corner. 
It's expected to be out fall of this year
(https://jdk6.dev.java.net/).

Just some thoughts.
Rob

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Fwd: [Dev] OSCON Slides

[Alex Karasulu <ao...@bellsouth.net>]

Hanson Char wrote:
>> I want to know what other users think about this idea of releasing
>> 1.0sooner without JMX support.  Any feedbacks are welcome!
> 
> +1.  That would be awesome.
> 

Yeah let's release MINA 1.0 before ApacheCon and make a nice 
announcement about it.

Alex

Re: Re: Fwd: [Dev] OSCON Slides

[Hanson Char <ha...@gmail.com>]

>I want to know what other users think about this idea of releasing
>1.0sooner without JMX support.  Any feedbacks are welcome!

+1.  That would be awesome.

Hanson

Re: Re: Fwd: [Dev] OSCON Slides

[Trustin Lee <tr...@gmail.com>]

Hi Rob,

On 9/5/06, Rob Butler <cr...@yahoo.com> wrote:
>
> Hi Trustin,
>
> Thanks for the info.  I've actually been hanging out
> on the Mina list for a while and even submitted the
> UDP configuration bug that you fixed for 0.9.5.  I
> plan on implementing a couple of different types of
> servers on top of Mina's core, so the work you guys
> are doing is pretty important to me.
>
> I cc'd this message to the mina list as most of these
> questions are mina specific.  Anyone who want's to
> catch up on the thread can view the original posts
> here
> http://www.safehaus.org/pipermail/dev/2006-September/000884.html
>
> I pretty much agree with all the comments you made,
> except the one below struck me as kind of odd.
>
> > > >*) AsyncWeb uses the older concurrent library
> > > > instead
> > > > >of Java 1.5's library.  Of course, if you want
> > to
> > > > run
> > > > >on 1.4 still this wouldn't be possible.  Have
> > you
> > > > >considered making 1.5 a requirement?
> >
> > Dave is leading the project, so I don't know what
> > exactly his plan is, but I
> > think aigning the overall plan with MINA would be
> > nice.  MINA currently runs
> > with JAva 1.4 and we will maintain this
> > compatibility in MINA 1.0.  We will
> > aggresively utilize Java 5 constructs from 1.1.  So
> > AsyncWeb will also
> > benefit from all the changes made from 1.1.  Vinod
> > Panicker told me that
> > changing MINA's internal thread pool implementation
> > to use Java 5 concurrent
> > utilities improves performance dramatically.
>
> Why stay with 1.4 compatibility for Mina 1.0 when you
> plan on going to 1.5 almost immediately?  Is it just
> to get a "1.0" released relatively soon?  Is it
> because ApacheDS has a dependency on Mina and couldn't
> re-fit to Java 1.5?


Version numbering in MINA resembles that of Linux.  1.0 is a stable branch,
and 1.1 is unstable.  So we will maintain 1.0 while we develop 1.1.  Two are
maintained separately.  That's why we can do whatever experimental or
radical with 1.1.  Any bugs in 1.0 will be fixed in 1.0.x, not in 1.1.x.

The reasons I feel staying with 1.4 is odd if you plan
> on going to 1.5 for Mina 1.1 are:
>
> *) Users of Mina 1.0 will have to upgrade to Java 1.5
> when they want to use the next version of Mina.  This
> will likely be a fairly drastic change similar to the
> changes between 0.8.0 and 0.9.5.  Why put your users
> through this pain?


As I explained above, 0.9.x is a unstable branch, and that's why we are
adding a lot of new features and changing some methods.  People who cannot
bear with this change could use 0.8.x.  We are going to release 0.8.3 very
soon.  Actually I had to fire a vote for this, but I forgot, doh! :)

*) 1.5 offers a good speed improvement and has been
> out a long time now.  Most Mina projects (with the
> exception of AsyncWeb and ApacheDS) will probably be
> new development.  I would expect anyone starting a new
> project to use 1.5 and not be stuck with 1.4.
> Sticking with 1.4 compatibility in Mina impedes
> projects starting to use Mina from taking full
> advantage of 1.5.


I agree, and that's why we want to move to 1.5 as soon as possible, 1.1.

When do you expect Mina to release 1.0 final?  Taking
> a look at Jira I see only 4 issues in the 0.95 or 1.0
> versions.  Personally I think the JMX integration
> (DIRMINA-29) could take a back seat until after 1.0 is
> released.  Hopefully the other 3 could be buttoned up
> quickly.  If you intend to address a significant
> number of the unscheduled issues before 1.0 it's going
> to be some time before 1.0 can be released.  That
> would make moving to Java 1.5 sooner even more
> important.  Heck, Java 1.6 is just around the corner.
> It's expected to be out fall of this year
> (https://jdk6.dev.java.net/).


I can't agree more with you here.  JMX integration is actually an optional
feature that shows slow progress recently.  We can take care of other API
design issues first and release 1.0 first.

But I talked that JMX support will be included in 1.0 to many people at
ApacheCon, and now... I just hope they understand me!  :D

I want to know what other users think about this idea of releasing
1.0sooner without JMX support.  Any feedbacks are welcome!

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6