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....
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
- 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
* 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)
* we should allow a queuing mechanism to be put in between each filters
* the Head and Tail filters are useless : they should be removed
* a chain may not be a list of filters. It can be a graph
- 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.
* the executor filter could be present in moe than one place in the
chain (SEDA)
* statistic must be established with a filter
* we should define two interfaces for filters : IngoingFilter and
OutgoingFilter. They will expose the methods to process ingoing and
outgoing messages
- 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
* we should add a sessionManager instead of all the existing queues used
to manage the dead sessions, the idle sessions, etc.
* session should not necessarily be associated with a processor.
* If a session is statefull, then we should attach the data to the
channel instead of creating a map for that
* 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
- codec
* we don't have stateful or stateless codecs. We should distinguish the
two kinds of codec someone can use.
* we should efine a collection of existing codecs
* as we can handle more than one protocol, we must add a demuxingCodec
which point to the next filter, conditionally
- Buffer
* We should not wrap ByteBuffer into our own IoBuffer class. We should
have a list of ByteBuffers instead, containing all the ByteBuffers.
- General
* offer a NIO 2.0 library
This is just a starting point ... Feel free to comment, add or remove
some items !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
