Hi Rob, On 9/5/06, Rob Butler <[EMAIL PROTECTED]> 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
