I agree with everything that you all have said here. The one thing I would add is about the documentation/tutorials. I look around at some other projects and sometimes the documentation is better, sometimes its worse. Focusing on the better projects, the documentation is spot-on professional. I have been working with ActiveMQ lately and the whole idea of the Enterprise Integration Patterns (EIP) is fantastic. It shows use cases and associated documentation. I think this is what we need. If you want an SMTP server do this, if you want an FTP server do that. The list goes on and on.
I think part of the problem with documentation is that the learning curve on the MINA internals is steep. I have been on the project for a couple years and only in the last 4-6 months can I say that I really understand the entire system. This makes it tough for people to dive in an help. ...just my $.02 On Tue, Aug 26, 2008 at 7:38 PM, Edouard De Oliveira <[EMAIL PROTECTED]> wrote: > Hi guys, > Little late on the subject > but better late than never as people says > Code features : >>- integrating proxy patch > The proxy connector needs some javadocing and maybe some tighter integration > with the core as it was > primarily intended to work out of the box without any core modifications. > Some comments from the team > would be much appreciated as sometimes it is difficult to question myself > after so much time thinking on it > fresh eyes could open fresh perspectives. > >>- composite buffers and streams based on it > There seems to be much interest on this feature avoiding buffer copy is > definitely a must have > +1 > >>- killing IoBuffer > Need some pointers on this discussion about the downsides of it. >>- fixing logging filter > I like Julien's hardcoded way because log filter is a debugging tool (maybe > we should rename it to DebugFilter as well) > but i would add some booleans to enable/disable event logging programatically > on a method basis > to make it fully configurable. > >>removing netty2 codec module (who want to use it for Mina 2.0 ?) > - who is using it ? is there any advantage which is not already built-in core > ? if so should we port it ? > >>test coverage (yeah painfull at this point) > +1 > >>write traffic throttling > +1 this is tricky and providing as much help on this subject will help > community > >>Doc feature : > +1 to the whole doc effort > >>state of the art release tarballs > Rpms and stuff is not a priority for the 2.0 release in my own opinion too. > Need to look closely to the tarballs to make structure improvements > suggestions > >> new website, clearer, and with better integration/links to >> subprojects like ftpserver and asyncweb > Pretty simple example it's hard to find the svn repository link so it's not > really a whole start over > that is needed but maybe a clearer navigation > Hope this helps. > Cordialement, Regards, > -Edouard De Oliveira- > http://tedorg.free.fr/en/main.php > > > > ----- Message d'origine ---- > De : Emmanuel Lecharny <[EMAIL PROTECTED]> > À : [email protected] > Envoyé le : Mardi, 26 Août 2008, 10h55mn 15s > Objet : Re: 2.0 Roadmap ? > > Hi guys, > > sorry for not having replied to this mail yesturday, I was busy with > personal stuff. > > Thanks Julien for having done this summarize. I have to add that we > didn't discussed all of the items on the list with Julien, but this is a > very good thing that Julien added the important items. We badly need a > roadmap for 2.0, taht's for sure. > > Comments in line > > Julien Vermillard wrote: >> Hi, >> >> next step is to create a wiki page due to the size of the list :) >> > Certainly. >> >>> <snip/> >>>> Code features : >>>> >>>> - integrating proxy patch >>>> >>> Don't know what this is about. >>> >> https://issues.apache.org/jira/browse/DIRMINA-415 >> >> Edouard big patch for supporting proxy such as simple port forwarding >> and SOCKS. >> It's somewhat a big patch to shallow. >> > ok. We have to look it closely. >> >>> >>>> - 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. >>> > We need to discuss this item on the ML, as it will imply a hell lot of > modifications. >>> >>> >>>> - killing IoBuffer >>>> >>> +1 >>> > Sure, +1. >>> >>>> - fixing logging filter >>>> >>> +1 >>> > I will create a JIRA plus submit at least two proposals (code) >>> >>>> - removing netty2 codec module (who want to use it for Mina 2.0 ?) >>>> >>> +1 >>> > +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. >>> >>> >> >> Emmanuel said me exactly the things word for word ;) >> > We are sharing a lot with Alex, but more important, we have empowered > each other to work better : removing bad habits ("Human habits ..." :) > by learning from the other, and listening to criticisms. Here, we were > on the very same page. It's also something we have gone through as we > are not young bloods... call it experience ! >> >>>> - 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. >>> >> >> I wrote a little resume here of ADS problem : >> http://cwiki.apache.org/MINA/traffic-throttling.html >> >> I don't understand why it's not doable using WriteFuture. >> Would be very kind if someone of ADS can take 5 minutes to explain me >> where I'm wrong. >> > I will try to explain the problem we have. May be I'm also missing some > points. >> >>> >>>> Doc feature : >>>> - testing and perhaps tuning APR based transport >>>> >>> +1 >>> > +1 >>> >>>> - doc on reqres filter >>>> >>> Have not had the pleasure of looking at this filter at all - don't >>> know what it's for. >>> >> >> it's for request/response protocols, so when you send a request you can >> listen for the response in a non blocking way. >> The whole module is doc less. >> > ok. So +1 >> >>>> - finishing doc on transports (core/APR/serial) >>>> >>> +1 >>> > +1 >>> >>>> - overall documentation (tutorial, concepts) >>>> >>> +1 >>> > We badly need tutorials. Also, a while back, we discussed about buidling > a kind of Ethereal on top of MINA. The biggest advantage of doing so > (having a protocol codec for many well know protocols) is that people > who want to learn about MINA will have real life samples on how to > implement a protocol on top of MINA. Good candidates for such codec are > obviously HTTP, FTP or LDAP (which is quite complex). >>> >>>> - new website, clearer, and with better integration/links to >>>> subprojects like ftpserver and asyncweb >>>> >>> +1 >>> > +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. >>> >>> >> >> Well MINA is a lib, so perhaps releasing linux package is a bit extreme. >> Some of the work was already contributed, we just need to find a >> workaround for a maven assembly bug. >> > Yeah, may be not necessary to deliver a rmp/deb. Maybe interesting for > AsyncWeb or FTPServer. >>>> 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. >>> >> >> What is amazing, it's the simplicity of the API and the complexity of >> the internals, it's sure NIO is not helping us here, but the is a lot >> of things to fix/document in core. Emmanuel raised a good example with >> LoggingFilter. >> >> The death of IoBuffer will probably be the first big simplification of >> the code base. >> > Damn yes ! IoBuffer represent itself around 15% of the code. > > There is another aspect which is cumbersome and complex : the filter > chain. I personnally don't think we need to have such a complex > implementation (the chaining concept is ok). For instance, we have a > HeadFilter and a TailFilter, I don't think we need them. Plus I also > think that we should distinguish between the incoming chain and the > outgoing chain. last, not least, we may need to have more than one > chain, as events may not have the same pathways. This is something we > have to think about. > Another reason why the current implementation sucks, is taht when it > comes to debug it, it's really a PITA. > >> >>> 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 >>> >> >> Yep actually MINA contributors are all hobbyist in the number of hours >> allocated, so we need reasonable target. >> > The current community is pretty wealthy, and I'm quite please to see > that ithere is a lot of positive energy, and new blood. Also we are not > in a hurry, as we don't have to deliver MINA 2.0 in 3 months. We can > spend a few extra months in order to get a good 2.0 MINA. And I don't > want to have a 2.0 out if this is just to start working on a 3.0 which > will be almost a complete rewrite. > > Thanks Julien ! >> Julien >> > > > -- > -- > cordialement, regards, > Emmanuel Lécharny > www.iktek.com > directory.apache.org > > > > _____________________________________________________________________________ > Envoyez avec Yahoo! Mail. Une boite mail plus intelligente > http://mail.yahoo.fr
