Hi David, On 9/23/06, David Lee <[EMAIL PROTECTED]> wrote:
Cindy(http://cindy.sourceforge.net) is another project which do the same thing like MINA. I think mina developers can benefit from it more or less. Though it's less feature than MINA, I prefer its user-interface which style is more simple than MINA.
Thank you very much for the heads up. I looked into it briefly. I found some differences: * Cindy doesn't have IoService/SessionConfig. It has properties in SessionAcceptor or Session directly. I think having separate config interfaces are better. * Cindy moved static methods in ByteBuffer into ByteBufferFactory. This is reasonable, but I prefer ByteBuffer.allocate because it's shorter to type unless there's a major improvement in doing that. * Cindy exposes Packet interface to send data. MINA uses WriteRequest internally, and it's not exposed to users. Exposing Packet gives an interesting feature called 'high priority write'. Do we need this feature for MINA, too? * Reactor pattern from ACE. I think this is just another abstraction layer on top of NIO Selector. Java NIO already provides an abstraction layer; do we need another one for MINA??? * Cindy has Session.start(). It is used for initiating a new connection or accepting an incoming connection. It makes the code simpler for client applications, but not for server applications. One advantage for server side is that a user can create multiton handlers for one service. I once tried this idea by creating an IoSessionHandlerFactory, but it has been rejected by community and replaced with handler.multiton package. I still think IoSessionHandlerFactory is a good idea even though there's an extra parameter issue with it. Actually, an extra parameter for event handler methods are often very useful. * Cindy's Acceptor can bind to only one port. It makes the interface simpler, and I like it. MINA's Acceptor can bind to multiple ports, so one I/O service can provide multiple services, which is a little bit confusing. Any comments on my comparison are appreciated. 1. The package arrangement of Cindy is more clear. I think MINA should
better put core Class in org.apache.mina rather than create another org.apache.mina.common so that a beginer can not get lost in package layer. Another reason is I hate long package name:)
You are right except the long package name, which is taken care automatically by modern IDEs. Reorganizing the 'common' package was on my to-do list, but it won't happen in 1.0. We will perform necessary refactoring in 1.1. BTW, what is more important is documentation and tutorial. We need to focus on them seriously before announcing 1.0 even though we release 1.0 first. 2. The naming of class is better in Cindy, I think. Someone wants to
use some facility of MINA not only to realize a protocol, but also implement service logic. Fore example, maybe some programmer wants to use IoSession not only to hold an I/O state, but also for a business session. But lots of class in mina starts with "IO" which make me feel unnatural. Another example is IoFuture can also be use without I/O with the same reason. and so on...
This is very controversial. You will probably use your IoHandler implementation to translate protocol request messages to the operation on a business object. If you are putting business logic such as DB access directly there, you will end up with another messy class. You have to use IoHandler as a protocol flow implementation rather than direct business logic implementation. 3. IoFuture.join() is use for waitting the result of a asynchronous request
in mina, while Cindy use Future.complete(). I think complete() is better, because it illuminate the function on the view of user, while join() illuminate the function on the view of thread.
Sounds like a good idea. If there's no objection, I'd like apply your suggestion. I think MINA is useful to realize high-concurrency server in telecom or
online-game domain, if it's not limit itself in protocol realizing. It's easy to achieve the goal if MINA add some feature like stage/action/task after Handler to separate the long service logic in lots of segments
I agree with you, but it's not always true for everyone. Actually, I am trying to generalize MINA into a general pipelining framework, but it's not so easy to retain the ease of use for network applications after redesign of the API. So I think just providing integration with well known components such as XWork or ServiceMix. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
