What are the plans for release of 2.0 and the migration to a 3.0 development? Is anyone prototyping any of these ideas in sandboxes?
On Thu, Jun 11, 2009 at 7:55 AM, Emmanuel Lecharny<[email protected]> wrote: > I have created a Wiki page containing this discussion : > http://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design > > Julien Vermillard wrote: >> >> Hi, >> reply inline >> >> Le Wed, 10 Jun 2009 21:37:10 +0200, >> Emmanuel Lecharny <[email protected]> a écrit : >> >> >>> >>> Hi guys, >>> >>> as I'm commuting every day for a long distance, I have had time to >>> think about what I would see in MINA 3.0. Here is the result of my >>> random thoughts.... >>> >> >> And not see anymore ;) >> >> >>> >>> Mina 3.0 design and expected features >>> ------------------------------------- >>> >>> - selectors usage >>> We should be able to define the number of selectors to use, and to define >>> what they will be used for. For instance, atm, we have a >>> selector in the Acceptor, plus a selector per Processor. This is not >>> necessarily the best solution. >>> >> >> >>> >>> * do some perf tests to see if it's better to use one or many >>> selectors. >>> * decouple the selector usage from the the selector definition. It should >>> be possible to define one single selector and use it in many >>> places >>> * the Acceptor and Processor should not necessarily be associated >>> with a thread. it's up to the user to define the thread model to use >>> >> >> Actually look like we need different strategy for different usage. On the >> right threading/selector strategy look like there is no real >> consensus and we will need to experiment for finding the default >> solution. >> >> >>> >>> - Chain >>> The current chain implemention is cumbersome. We would like to have >>> something easier to manipluate, and also easier to debug. >>> >>> * the chain should be optionally dynamic : a session can add a new filter >>> in the chain whenever needed >>> * we should not always copy the chain in each session, if the chain >>> is immutable >>> >> >> Yes, cause most of time we configure the chain on the acceptor and >> never change it again. >> Look like we agreed on copy-on-write for that. >> >> >>> >>> * however, it should be possible to change the global chain without >>> breaking the processing. >>> * we should have one chain for incoming messages, and another one for >>> outgoing messages >>> * it should be possible to have a multi-stage codec (ie, add more >>> than one codec filter in the chain) >>> >> >> Mandatory, it's very often I use a TextLineCodec and a String-to-Pojo >> filter, and I'm sure I'm not alone. >> >> >>> >>> * we should allow a queuing mechanism to be put in between each >>> filters >>> >> >> What is that for ? Look like you got a new idea :) >> >> >>> >>> * the Head and Tail filters are useless : they should be removed >>> >> >> Yes >> >> >>> >>> * a chain may not be a list of filters. It can be a graph >>> >> >> If we can keep the API simple enough, why not. >> >> >>> >>> - Filters >>> >>> * a filter should accept a stream<Object>, the Object can change from one >>> filter to another. it's up to the user to correctly handle the >>> Object. >>> >> >> You want to say multi layer codec ? >> >> >>> >>> * the executor filter could be present in moe than one place in the chain >>> (SEDA) >>> >> >> Mandatory if someone really want SEDA. >> >> >>> >>> * statistic must be established with a filter >>> >> >> Again mandatory. >> You won't do stats the same way on HTTP or FTP and stats can be very >> costy. >> >> >>> >>> * we should define two interfaces for filters : IngoingFilter and >>> OutgoingFilter. They will expose the methods to process ingoing and outgoing >>> messages >>> >> >> The question is where to put sessionOpen/Closed/Idle in a two chains >> model. >> >> >>> >>> - Session >>> * we should have two kind of sessions : statefull and stateless. >>> Sometime, we don't need to store any kind of information in a session >>> >> >> If we create the HashMap on first additon, where is the gain ? >> >> >>> >>> * we should add a sessionManager instead of all the existing queues >>> used to manage the dead sessions, the idle sessions, etc. >>> >> >> We need to rethink the whole separation between IoProcessor and >> IoService and where we manage closing/accepting queues. >> >> >>> >>> * session should not necessarily be associated with a processor. >>> >> >> +1 >> >> >>> >>> * If a session is statefull, then we should attach the data to the >>> channel instead of creating a map for that >>> >> >> Can you say more about that, where is the gain ? >> >> >>> >>> * A session must be attached to an acceptor, allowing more than one chain >>> if the acceptor is to deal with more than one single >>> SocketServer >>> >> >> We need to find away for running more than 1 kind of port/protocol with >> the same set of Thread/Executors. I suppose it would be interesting >> for ADS. On my side I run servers with 3 or 4 SocketAcceptors for >> different protocols, somthing like 10 SocketConnectors for different >> protocols. >> Perfs aren't an issue for me actually, be it can change. >> >>> >>> - codec >>> * we don't have stateful or stateless codecs. We should distinguish >>> the two kinds of codec someone can use. >>> >> >> +1 >> >> >>> >>> * we should efine a collection of existing codecs >>> >> >> For that we need a standard way of doing a codec on the Pojo side. >> I'm sure LDAP pjo oof ADs are very different (and got different >> dependencies) of the one of Asyncweb or Vysper. >> >> >>> >>> * as we can handle more than one protocol, we must add a >>> demuxingCodec which point to the next filter, conditionally >>> >> >> Here the graph ? :) >> >> >>> >>> - Buffer >>> * We should not wrap ByteBuffer into our own IoBuffer class. We >>> should have a list of ByteBuffers instead, containing all the >>> ByteBuffers. >>> >> >> And some extended Stream interface for manipulation. >> >>> >>> - General >>> * offer a NIO 2.0 library >>> >>> >> >> Well it's going to be soon mandatory :) >> >>> >>> This is just a starting point ... Feel free to comment, add or remove >>> some items ! >>> >>> >> >> We need at first a great test platform for testing the different >> protocols and implementation ideas (Thread/Selector/Channel >> strategies). So we make choice based on facts for the engine. >> >> Julien >> > > > -- > -- > cordialement, regards, > Emmanuel Lécharny > www.iktek.com > directory.apache.org > > >
