Trustin, On Jan 21, 2008 2:07 AM, Trustin Lee <[EMAIL PROTECTED]> wrote:
> With the discussion of Dave (the original author of AsyncWeb), we > agreed to include the HTTP message model and codec into MINA, and make > AsyncWeb focus on more high-level features like session management and > proper error handling that turn a mere codec into a real world web > server component. It's like AHC (AsyncHttpClient) is trying to do the > same with the MINA HTTP codec. > He communicated to me that he was somewhat pressured into this decision and was not feeling too good about that. I hope that's not the reason for loosing him. Another extracted portion of AsyncWeb is the state machine based codec > I wrote all. That's fine if you wrote it. It's a very general codec component that can be used to > build virtually any kind of protocol, so it has been included into > core. That's fine and irrelevant since it can be and has been separated properly. > The state machine based codec > (org.apache.mina.filter.codec.statemachin) has absolutely no > dependency on AsyncWeb. HTTP codec depends on it though. > I saw these recent changes made since the move from Safehaus.org. It is separate and that is fine. And, I personally think providing the codecs for essential protocols > such as HTTP, FTP and SMTP as a part of the main MINA distribution > makes a developer's life much easier when what he wants is just a > minimal client / server. This is not about making MINA the end all be all to everyone. Where do you draw the line? (1) Are you going to ask FtpServer folks to move their codec into MINA proper as a submodule? (2) Are you going to ask JAMES people to move codecs they build on MINA to move them into MINA? > That's what I've been talking in ApacheCons > and you can see that clearly in my slide files, which were uploaded in > the official site since 2005. That's fine for you and your personal dreams about MINA expansion and growth etc, but overall for the ASF this is not the most optimal community oriented direction. > It's interesting that nobody argued > about the road map I proposed since then. The idea is now being put to the test and is a very bad one. I provide the reasoning why at the end of this email. And you're right it is the "road map [you] proposed" and roadmaps change. If this is a community now, you need to stop and consider that this might no longer be the right direction instead of pushing it. Roadmaps get updated. > Actually we got some > positive feed back related with the HTTP codec from users due to this > decision. Additionally, look at our PMC charter: > > > http://svn.apache.org/viewvc/directory/sandbox/proyal/MINA-TLP-Proposal.txt?view=markup&pathrev=437911 > Resolutions are not always perfect and may need to change to adjust to living breathing communities that sense and respond to the conditions. These are not the 10 Commandments so don't freak out; we can update it. I know the board, the membership and PMCs would support any change that protects communities, MINA's, as well as, protocol projects budding out of MINA. I am also certain that others interested in bringing about new projects based on MINA would agree that it's a bad idea to strip their protocols and move them into MINA proper. > > The idea itself about the road map was proposed since the MINA PMC is > formed. We can strip down what we are doing, but I see a lot of > synergy of providing some protocol codecs. Of course, this doesn't > mean we have provide all kinds of protocols or high level features on > top of it in the official MINA distribution. Again this has issues and they are outlined at the end of this email. > > BTW providing AHC as a subproject might be a good idea - for now it's > included as a MINA submodule, but we can provide it as a separate > subproject. I'd like to know what Jeff thinks about it. > It's not just AHC. Please don't try to separate the two to break down this project's chance of survival. Asyncweb naturally goes with AsyncHttpClient: one is the server and one the client. The client and the server for HTTP should be kept together in the same subproject but as separate modules perhaps. But that should be up to the people working on the async HTTP code. It's one cohesive unit and you should not try to break that cohesion. It was agreed to bring the Asyncweb project here from Safehaus.org<http://safehaus.org/>to the MINA TLP until it could gel a sufficient user and developer community. The intent was very similar to the reasons for bringing over the FTPServer project to MINA. There was no intention to strip the Asyncweb code base of it's HTTP codec logic and integrate it into MINA proper. If codec stripping was not the case, although subversion shows otherwise, then another codec was created in MINA and the Asychweb HTTP codec was replaced with this new HTTP codec filter. Either way this practice is wrong and should not continue. Inevitably, other protocol subprojects based on MINA, besides FtpServer and Asyncweb, will arise or migrate here. Some may stay indefinitely but some will inevitably graduate into their own TLP as their protocol specific community hopefully grows to sustainable levels. This is going to be a common model and something we should promote rather than inhibit. We cannot start stripping codecs out of these projects while pushing their protocol specific codecs into MINA proper. This would have severe disadvantages as outlined below. Stripping codecs out of protocol subprojects to put them into the MINA subproject would hence: (1) bulk up the MINA subproject while stripping many protocol servers down to insignificant shells wrapped around MINA libraries (2) severely impede the growth of community around separable protocols based on the MINA API (**3**) require protocol subprojects to release MINA proper whenever changes are made to their codec interfaces (4) turn MINA into a monolithic TLP that is hard to manage as is the case with Jakarta (5) force subprojects to have to participate in the MINA community while mixing concerns: lurkers interested in one protocol will have to deal with all messages pertaining to all codecs and MINA proper (6) deter the genesis or migration of new protocol projects at/to MINA if MINA cannibalizes their codecs [NOTE: #3 is a major issue for me right now but all these issues as an ASF member concern me deeply] For all these reasons, the MINA subproject should not contain the HTTP protocol codec and it's HTTP specific interfaces like HttpRequest and HttpResponse. It makes no sense to hinder or hold the Asyncweb community dependent on MINA releases just because HTTP interfaces need a tweak: consider for example HttpRequest or HttpRequestDecoder which are kept in MINA's filter-code-http module. If for example there are changes to these HTTP interfaces Asyncweb releases will require a MINA release when the core of MINA may not change at all. These tenants are generally applicable to all protocols and protocol subprojects that might find a permanent or temporary home here under the MINA umbrella. By stripping out the HTTP codec in Asycweb, you essentially turned off a core committer who felt you were cannibalizing the project to benefit MINA. But Dave can speak to this. The project almost died before it could get off the ground because of this. Fortunately there are many people out there still interested in Asycweb and we don't want to let this happen. So the first order of business is to put it back together after you stripped out it's core. This will break the link between MINA releases and Asyncweb releases at the most basic level. IMO this is very poor community dynamics. Think back to when MINA was at Directory: Everyone wholeheartedly supported MINA and now something richer has come up because of it. No one held it back trying to keep it in Directory because we felt we needed more code or substance. Entire communities around protocol projects based on MINA need to be allowed to form just as the MINA community has gelled around the MINA code. Furthermore, I spoke to the old committers of asycweb and they are still interested but feel the IP clearance took so long. They're willing to contribute and support the project in one way or another. We have at least 4 people with most core committers still interested in this subproject: Timothy Bennett Dan Diephouse Alex Karasulu Jeff Genender Trustiin Lee [you count too] I will start becoming active on this code base again and supporting it as Jeff has pledged to as well. Try not to squash this effort, but rather, promote it so something bigger can happen instead of including the HTTP codec to add fat to MINA. Thanks, Alex > On Jan 21, 2008 3:05 AM, Alex Karasulu < [EMAIL PROTECTED]> wrote: > > Hi, > > > > MINA 2.0 is pushing the inclusion of specific protocol codecs into the > core: > > I am specifically referring to the filter-codec-http module. > > > > Who decided on this policy and why? Trustin, according to SVN logs you > > commit this and it seems as though some of it was extracted from or > overlaps > > the asycweb functionality. > > > > What is the intention for asyncweb as a subproject if it's functionality > is > > being moved over to MINA core? > > > > Thanks, > > Alex > > > > > > -- > what we call human nature is actually human habit > -- > http://gleamynode.net/ > -- > PGP Key ID: 0x0255ECA6 >
