mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [MINA 3.0] Chain Transition aka nextFilter() Calculation mechanism
Date Sun, 13 Dec 2009 04:47:25 GMT

On Dec 9, 2009, at 10:56 PM, Ashish wrote:

> Folks,
>
> Had a brief chat with Emm today regarding implementation of Filter
> Transition mechanism.
> Attached is the summary for further discussion(s)
>
> Problem Statement
> -------------------------
> 1. We need a way to determine next filter in chain
> 2. We need flexibility in the calculation mechanism for plugins like
> users can plugin their own transition mechanism for eg State Machine
> based
>
> Summary
> ------------
> The discussion was around the nextFilter API. There were two option,
> have this in chain or have this in Filter. Having the API in chain was
> a better option
> as chain has access to the complete Filter list. So we are looking at
> an API something like
>
> IoFilter nextFilter(IoSession session);
>
> or
>
> IoFilter nextFilter(IoFilter currentFilter, IoSession session);
>
> The second API is to cater to scenario where the chain needs to know
> which the current/previous filter in the chain.
>
> How it works
> ----------------
> While the chain is being traversed, the IoFilters that have access to
> the Chains, shall ask for the next Filter. Based on the return
> type we call api like
>
> messageReceived(..) {
>
> //get next Filter
>
> // fire next filter message received
>
> }
>
> Its two steps :-(.
>
> The default Chain implementation shall be based on LinkedList.
>
> So if someone wants to customize the way next filter is supposed to be
> called, they can have custom implementation of nextFilter() API
>
>
> Open for feedback on this. Please add if we have more
>
> 1. Does this API suffice to the needs that the Users may have? Alan,
> will you be able to plugin State machine transition based on this
>
> 2. Do we need some specific TransitionFilter or some class in the
> Filter chain that makes plugging in the implementation simpler.
>
> Julien: will be able to handle the stateful codecs?
>
> The stage is open for discussion :-)

IMO, this is overly general and a simpler fixed state machine will fit  
the bill.


Regards,
Alan




Mime
View raw message