Am 07.07.2015 um 12:34 schrieb Emmanuel Lécharny:
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.
Thanks. I will look into this.
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.
Sure, for you guys who wrote that stuff it was easy ;-)
btw: The MINA git repo is also available on github. Is it possible to
fork the project on github, work on some parts (documentation etc.) and
create pull-request that you guys then review and merge? Or do I have to
do it all via the official apache git repo?
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.
Guess what: My stuff is also just a private open source side project. I
know exactly what you mean. It also took my about 2 yrs to finish a release.
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?
MINA 2 works quite well.
But for my next version, I expect from MINA more clean code, maybe more
performance, and of course on the long-term, better support.
My next release - maybe end of this year - will be a first milestone.
There will be a lot of changes in. And for me it would sense to invest
in the future (MINA3) than staying with an very old version and do
another big change in my library in another big release.
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.
All in all: sounds good...
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 :-)
I completely understand. But I don't think that this will change in
future. It's the same with every other OSS...
Personally, my intention to work in my open source library is: Its THE
solution for my software-problem. So I work on it and improve it, so
that the result is getting bigger and better. I made the lib open
source, so that others can benefit from my work (GPL). So I don't do it
for others. Actually I do it for me.
And if other's want to make money, the have to pay license fees (dual
licensed). That does not create a big income. But from time to time I
can wine and dine with my wife.
