Hi all, On Mon, Aug 25, 2008 at 5:18 AM, Julien Vermillard <[EMAIL PROTECTED]>wrote:
> Hi, > > After meeting Emmanuel IRL, we agreed we need to discuss some kind of > little roadmap for 2.0, and sort JIRA issues > Excellent, thanks for summarizing here. > > Code features : > > - integrating proxy patch Don't know what this is about. > > - composite buffers and streams based on it I definitely want to get involved here but I need to catch up on the conversations had in the past about it. > > - killing IoBuffer +1 > > - fixing logging filter +1 > > - removing netty2 codec module (who want to use it for Mina 2.0 ?) +1 > > - test coverage (yeah painfull at this point) Yeah test coverage is important but luckily MINA is not that large. Test coverage makes it easier for people to get into the code to try to add features or fix a bug while knowing their changes/fixes will not cause regressions or breakage in the behavior of the API. Plus it's the best example code to use for how to learn to use different features of MINA: I always look at test code when learning how to use a new piece of OSS since the docs may not be there or may not be totally up to date. > > - write traffic throttling Yes this is a concern of mine as well. I've been experimenting in the last few days specifically with ApacheDS trying to get her to behave like a lady (u know not giving everything she's got and overwhelming clients). I realized we need to support the MINA community by making the move to MINA 2 ASAP. Was going to do this last night but was wrestling with Maven issues. We'll probably make the move shortly and can supply a lot of feedback with respect to this aspect. > > > Doc feature : > - testing and perhaps tuning APR based transport +1 > > - doc on reqres filter Have not had the pleasure of looking at this filter at all - don't know what it's for. > > - finishing doc on transports (core/APR/serial) +1 > > - overall documentation (tutorial, concepts) +1 > > - new website, clearer, and with better integration/links to > subprojects like ftpserver and asyncweb +1 > > - state of the art release tarballs +1 I think might we have some reusable infrastructure over at Directory that might help with this and things like deb, pkg, rpm installers. We're not starting completely from scratch in other words. > > The discussion is open, the idea is to gather wish and ideas, reach some > consensus and clear the list of issue in JIRA. > Personally I'm disappointed by MINA's internals and how complex it is. Another committer and I were discussing this complexity on IM a while back. He said, "I have not read a single project that was great that did not have lucid crazy simple code. It's like what Feynman said about complex subjects: you don't really understand it. Same goes for code. If it's complex and obfuscated you don't understand the problem domain." I whole heartedly agree and there might be a need for some rearchitecting for the sake of simplification and clarity. This can be approached in phases with subtle refactorings of the internals without impacting the API. In general this will improve: - our ability to respond to bugs, - requests for new features, - increase the developer adoption rate with lucid code, - have better more discrete test cases for internals, - and better manage and interpret issues when internals are explicit in what they are designed to do After realizing that I need to step up, I've started reaclimating myself with the internals. I could not believe how disorderly it is: I thought it was in much better shape. In the present state, it's very hard to see people with limited time frames looking at the code and understanding it in time to actually affect some change. The barrier is too high but we can fix that one step at a time. Alex
