Le 07/07/15 12:02, Alexander Christian a écrit : > > > Am 07.07.2015 um 11:50 schrieb John Hartnup: >> Interesting read. It looks like we consumers of Mina have some work >> ahead >> of us if we choose to upgrade. > At least if you are an early adopter like me :-( > > I'm struggling with the ProtocolCodec. There is no example code which > demonstrated the usage.
There is one in the mina-coap sub-project. You can also have a look at the mina-http and mina-http2 codec (also mina-protobuf and mina-thrift). Of course, they are not samples, but tehy are full-fetured implementation of the Encoder/Decoder interfaces. > The question is: How was it developed if there is no example? Maybe > the example is not that nice and clean, but no example at all: Seems > you're completely lost. > As the class names and the concept are (slightly) > different/undocumented, it's very hard to find out how to do it right. I agree. For us, it was easy : we had Mina 2 to look at. But, yes, we need real-world samples in a separate project, *and* some documentation. > > The other problem I see: > 3.0.0-M2 (which is the latest milestone-release) is 23months old. > > If you don't know or see the people or the effort behind the > development, it looks like the project is fallen asleep. True. Although there are some progress, but at a slow pace. We all are quiet busy on side projects (those that pay the bill...), and family stuff. It's not easy to find some time to work on MINA, especially as it requires a few days without interruption to get things done. jeff was able to contribute a big chunk of code in April this year (the first part of the HTTP2 protocol), for instance. > > If I don't get something to work in next few days, I have to consider > changing the API. Maybe Netty, maybe something else... Or stay with > the also about 2 years old MINA 2 version I already use. I absolutely > have no idea. Ok, here, the question is : what would you feel like you *should* switch to MINA 3 ? is there something that is not working well with MINA 2? The reason we decided to start a full rewrite of MINA 2 were the following : - MINA 2 was designed in 2007, 8 years ago. It took almost 2 years to move from a 2.0.0-M1 to a 2.0.0-GA. In the mean time, Trustin left the project due to some arguments about the code quality, just after 2.0.0-M1 was out, and we had to get MINA 2.0.0 out. A hell lot of code refactoring, documentation, etc. All in all, some of the major issues we have in MINA 2 should be fixed : - the SSL handling has been completely refactored - we now use two chains, one for the incoming events, one for the outgoing events - we don't anymore depend on the IoBuffer, which was not extensible without copying all the data - the way Futures were used was insanely complex, it should be much simpler - we have added an API that could also work for block IO, something that is missing in MINA 2 (in other words, who cares if the underlying layer is blocking or non-blocking, as soon as the full logic built on top of it is the same ?) and many more. It takes time, it takes people to work on it. > > But MINA 3 currently seems to be a pain. > Of course I could become a commiter and push the current > developmentspeed a bit. But I'm busy with my library that currently > uses MINA.... That is the crux of the problem : if everybody expect that someone else will work on MINA, it won't move very fast. I'm not complaining about this situation, but I'm asking you to try to understand why we are slow :-) Somehow, it reminds me - to some extend - the OpenSSL situation last year, where everyone pointed fingers on the team in charge, but nobody wanted to participate or even pay the committers to work on the project (and here, I'm thinking about the GAFA fellows, who are quick to fork a project and work on it without contributing back...) That's life in the OSS world, we are doing our best, most of teh time, it's not enough, but we keep going... > >
