On 8/26/11 1:14 PM, Julien Vermillard wrote:
On Thu, Aug 25, 2011 at 2:29 PM, Edouard De Oliveira
<[email protected]> wrote:
On Wed, Aug 24, 2011 at 7:55 PM, Edouard De Oliveira
<[email protected]> wrote:
On 8/21/11 11:48 PM, Alan D. Cabrera wrote:
On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote:
But i'm feeling more and more confused by the fsm need : as you said some
management bits in the session can switch on/off some filters why do we want to
complicate the coder 's life using a two state FSM (in the case of multiple
filters it would generate a much more complicated FSM that the coder would
have to describe with code ... better ?) ?
Do you want the fsm to control the flow between filters (state=filter ?) or do
you want your fsm to control if a filter is active ?
There's no reason why one could not have a chain of FSMs. You get the exact
same behavior with less framework code.
The reason why MINA 1 and 2 has a chain is unclear. One possible explainaition is that
MINA was supposed to implement the SEDA>architecture (each filter communicate with
the next filter using a queue, and as this architecture is supposed to spread filters on
more than>one computer, then it's easier to implement it using a chain. Well, that's
my perception. One other reason was the lack of vision about the>possible use cases.
6 years in restrospect, I do think that this need never surfaced...
With the growing of the base code it's easier just by looking at what exists to
find some use case one would not have though of at this time
The more I think about this problem, the more I think that FSM is the way to go
:
- we don't add filters dynamically on a created session
- we *always* know which filter we will call whatever state we are : it's a
protocol we are handling, it's well defined !
+1 : it's just that it will require much more preliminary toughts to start coding
a server -> that's our good practices promoting thing
- debugging will be easier
i won't be so categorical about this as whatever graph type you use to describe
your 'chain' it will still be session/data dependent
- we won't have to use some strange Mutiplexer filter in order to call one filter
or another depending on the message we are dealing with, like>it's currently
the case in MINA 2
not so strange as it is a well known design pattern (Command Pattern)
- coding a protocol will be easier
we have to make basic servers easier (or as easy as before) too
- we can define @ to declare the FSM, making the developper's life easier (an
idea that needs to be developed...)
i was also planning on some @ (like @unique to limit the presence of a filter
in the chain or some more generic one that would provide the name and the
unicity of the filter for Mina 2 obviously)
for mina 3 i indeed was wondering if somehow we could use @ to prevent bloated FSM
declaration code and found this interesting article>which could be a good base
to start with :
http://weblogs.java.net/blog/carcassi/archive/2007/02/finite_state_ma_1.html
You can find a fast hack at the following pastebin url which shows how i
changed the original code of the article to add data dependent transitions :
http://pastebin.com/CjXjJ2Q1
Do we all agree on that ?
There's lot of momentum on this solution so it should be given at least a try
obviously
+1
it's hard for me to figure if it's going to be the solution witout a
more complex example implementation
it's far from being an implementation it's just a basic poc that a fsm can be
built with @
I modified the API to remove IoFilterChain. Now you are supposed to
give a list of filter to the service before starting it :
// create the fitler chain for this service
List<IoFilter> filters = new ArrayList<IoFilter>();
filters.add(new LoggingFilter("byte log filter"));
filters.add(new MyCodecFilter());
filters.add(new LoggingFilter("pojo log filter"));
filters.add(newMyProtocolLogicFilter());
acceptor.setFilters(filters);
I would like to have something like :
acceptor.addFilters(
new LoggingFilter("byte log filter"),
new MyCodecFilter(),
new LoggingFilter("pojo log filter"),
newMyProtocolLogicFilter() )
which is easy as soon as we have a Acceptor.addFilters( Filter...
filters ) method. (ellipsis notation is really very comfy)
thoughts ?
Otherwise, I'm fine with your approach.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
