You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2011/12/12 10:08:30 UTC

[MINA 3] heads up

Hi guys,

so this is a new week, and it was a busy week on MINA 3 last week. I'd 
like to sum up some of the ongoing work we have done so far, and things 
we have discussed on the mailing list or off list. Note that it reflects 
my vision, so feel free to correct me if I have made any mistake, or if 
I forgot anything.

SSL :
Handshake is now working. Data decryption is done, remains to plug the 
data encryption. This is for the server side. The SSL support on the 
client side still remains to be coded. We also have to handle many 
options, like authentication through certificates. Buffer manipulations 
should be improved. SSL configuration should also be exposed. Overall, 
it's probably a matter of two more weeks to have a complete SSL layer, 
but the basic SSL handling will be ready before.

Session Attributes :
We will probably fall back to the proposal done by Christian Schwarz, ie 
using some typesafe Attributes 
(https://issues.apache.org/jira/browse/DIRMINA-874). There are too many 
little issues with the other proposed solutions.

Read/Write handling :
Thanks to ChadBeaulac, we have now a much better solution to handle 
reads and writes. There is still some room for improvement, but it's way 
better than it was. We still have to make the buffer size configurable 
(right now, we are using a 1Ko buffer for reads, but we will switch to a 
64Ko buffer, and expose a way to configure this size).

Executor :
We still have to discuss this aspect. Basically, I don't think that we 
should include an executor into the chain. We should rather make the 
handler responsible for this aspect. Exposing two kind of handler -one 
using the selector thread, and another including an executor - is 
probably better. Still to be discussed.

Zero-copy handling :
At some point, we'd like to support the transferFrom/transferTo methods. 
That means we may augment the chain API by adding two new events to 
complete the write() and messageReceived() events.

Client implementation :
Right now, we have focused on having the base mechanism working for a 
simple TCP server. This is a good start, but we also need to implement 
the Client side. This is most certainly what we will work on as soon are 
we are pleased with the Server side.

UDP support :
Once the TCP client and server will be ready, we will switch to UDP. 
That will also include multicast support.

Multicast support and JDK version :
It's not sure we will support multicast for Java 6 and previous 
versions. Sadly, JDK 7 is arriving way too late and we will have to 
support Java 6 for years. It makes no sense to just tell our users to 
stop using Java 6, IMO. However, we have to discuss this aspect.

JDK version support :
MINA 2 supports Java 5 and further. The question should be raised about 
MINA 3 and Java 5 : should we continue to be Java 5 compliant, when this 
version has been EOLed last year ?

NIO 2 :
Not so much discussion about the support of this new API. I'm not sure 
it brings a lot of new additions, and we still have to figure out how we 
can support it without having to expose two versions of MINA

APR and Serial support :
Still to discuss if we should support both.

BIO :
That would be a good thing in MINA 3 could be used as a Blocking IO 
framework too. Still to see if it's possible, and to what extend. May be 
it's just a wet dream...

Administration :
MBean to the rescue... We need to think about it, seriously.

Protocol codecs :
It would be good if we could offer codecs for various existing 
protocols, instead of requesting users to develop them. Still to be 
discussed.

Doco and site :
Clearly a lot of things to do here. The site is, hmm, ok, not perfect, 
and the doco is totally inconsistent. We *must* provide a better 
documentation. We think that instead of using Confluence to write the 
documentation, we should switch to a file based documentation. We have 
done some experimentation on some other projects

Javadoc and Unit tests :
Same here : lots to do, but definitively mandatory. The Javadoc in MINA 
3 is not bad, but need some cleanup. Unit tests, that's clearly an area 
we should spend some time.

That's a lot on our plate, but if you feel like you can bring some value 
here, feel free to join us !


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


Re: [MINA 3] heads up

Posted by Emmanuel Lecharny <el...@gmail.com>.
On 12/13/11 5:57 PM, Christian Schwarz wrote:
> Community support: Actually we have the mailing lists and jira to 
> communicate in all directions. It both works well, but i think the 
> user communication can be improved. The mailing list doesn't provider 
> any styling of the text, so codesnippets are hard to read. 
> Stackoverflow can help here, there is actually a tag for MINA with 
> some questions-> http://stackoverflow.com/search?q=apache-mina . The 
> MINA development team could register a RSS-Feed for this tag to 
> provide support. There is a huge acceptance in the community for 
> stackoverflow ! Greetings Christian 

Forgot to say that we usually are hanging out on #mina, but this is 
reserved for technical discussions, not for any decisions.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


Re: [MINA 3] heads up

Posted by Julien Vermillard <jv...@gmail.com>.
On Tue, Dec 13, 2011 at 5:57 PM, Christian Schwarz
<ch...@googlemail.com> wrote:
> +1 for all points..
>
> ...and some comments and additions:
>
> Javadoc and Unit tests :
>> Same here : lots to do, but definitively mandatory. The Javadoc in MINA 3
>> is not bad, but need some cleanup. Unit tests, that's clearly an area we
>> should spend some time.
>>
> Talking about test what about codecoverage ? If u use eclipse as IDE
> http://www.eclemma.org/ can assist here!
>
>
> Community support:
> Actually we have the mailing lists and jira to communicate in all
> directions. It both works well, but i think the user communication can be
> improved. The mailing list doesn't provider any styling of the text, so
> codesnippets are hard to read. Stackoverflow can help here, there is
> actually a tag for MINA with some questions->
> http://stackoverflow.com/search?q=apache-mina . The MINA development team
> could register a RSS-Feed for this tag to provide support. There is a huge
> acceptance in the community for stackoverflow !
>
> Greetings
> Christian

Hi,
About coverage, it's tested with the jenkins build (see the little
graph at the bottom right) :
https://builds.apache.org/view/M-R/view/MINA/job/MINA-trunk-jdk1.6-ubuntu/

About stack overflow, I'm already register on this tag, but I'm quite lazy :)

Julien

Re: [MINA 3] heads up

Posted by Emmanuel Lecharny <el...@gmail.com>.
On 12/13/11 5:57 PM, Christian Schwarz wrote:
> +1 for all points..
>
> ...and some comments and additions:
>
> Javadoc and Unit tests :
>> Same here : lots to do, but definitively mandatory. The Javadoc in MINA 3
>> is not bad, but need some cleanup. Unit tests, that's clearly an area we
>> should spend some time.
>>
> Talking about test what about codecoverage ? If u use eclipse as IDE
> http://www.eclemma.org/ can assist here!
Gonna have a look at it.
>
>
> Community support:
> Actually we have the mailing lists and jira to communicate in all
> directions. It both works well, but i think the user communication can be
> improved. The mailing list doesn't provider any styling of the text, so
> codesnippets are hard to read. Stackoverflow can help here, there is
> actually a tag for MINA with some questions->
> http://stackoverflow.com/search?q=apache-mina . The MINA development team
> could register a RSS-Feed for this tag to provide support. There is a huge
> acceptance in the community for stackoverflow !
The thing is that at Apache, if it's not on the mailing list, it does 
not exist... So, definitively, we have to use either JIRA or the mailing 
list.

Some projects are currently being testing GiT at the ASF, and hopefully, 
we would be able to use that in 2012, making it easy to share code 
snippet (even if it's unlikely that github could be used).

ATM, for code snippet, the best would be to use a link to an external 
web site, like pastbin.com


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


Re: [MINA 3] heads up

Posted by Christian Schwarz <ch...@googlemail.com>.
+1 for all points..

...and some comments and additions:

Javadoc and Unit tests :
> Same here : lots to do, but definitively mandatory. The Javadoc in MINA 3
> is not bad, but need some cleanup. Unit tests, that's clearly an area we
> should spend some time.
>
Talking about test what about codecoverage ? If u use eclipse as IDE
http://www.eclemma.org/ can assist here!


Community support:
Actually we have the mailing lists and jira to communicate in all
directions. It both works well, but i think the user communication can be
improved. The mailing list doesn't provider any styling of the text, so
codesnippets are hard to read. Stackoverflow can help here, there is
actually a tag for MINA with some questions->
http://stackoverflow.com/search?q=apache-mina . The MINA development team
could register a RSS-Feed for this tag to provide support. There is a huge
acceptance in the community for stackoverflow !

Greetings
Christian