On Jan 21, 2008 6:39 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
<snip/> > and I also think it's time to get asyncweb out of sandbox. Sandbox is > supposed to be a place where we do experiments, or personal stuff. If > Alex wants to work on asyncweb, it may be time to 'wake up' the project > and put it back to trunk. Absolutely, if he wants to start to work on AsyncWeb. > > It makes sense I think! Would we still keep codec implementations in > > subprojects under mina/ (like filter-codec-http)? > > I think that each codec should have its own sub-project, with its own > versioning scheme. There is no reason why it should depend on MINA in > any way, except through a dependency. > > This is a dangerous approach which will be a real problem when > protocol's codecs will flourish, as you will have difficult time > synchronizing all of them when you will want to release a new MINA version. We have only one codec (or two including Netty? :) so far and didn't experience any problem yet. I'd rather wait and see more codecs to appear before we say that it will be a real problem. It doesn't hurt anyone. :) > > I think it would be very cool if MINA could be a repository for codec > > implementations like this and I think that has been your intention > > from the very start Trustin, right? We (Trillian AB) would be willing > > to contribute initial (and in some areas incomplete) codec > > implementations for POP3, SMTP and IMAP. I know there are others out > > there using MINA for various types of mail servers and clients. > > Together we could build complete and very usable implementations for > > these protocols. > > Codecs should be seen as plugins, and should have there own life, and > own versioning scheme. > > Does it make sense to you, guys ? Then what about other submodules like filter-compression, integration-*, statemachine and transport-*? Should they all be thought as plugins in the same context? Some components doesn't change a line when we cut a new release. What makes codecs so special? I see codecs as submodules that deeply depends on MINA constructs like other submodules does. A protocol implementation consists of a codec, message flow and business logic. A codec itself can't do anything at all. Codecs are very low-level component - you need something more on top of it to comply with the protocol, and that's why I think it should be a submodule of MINA distribution. Those only who understand how to use MINA API can use the codec. What's the use of providing it as a separate distribution? What's more important IMHO is whether we are going to provide the codec as a separate JAR file or not, and we are doing so already. Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
