On Aug 26, 2011, at 9:10 AM, Emmanuel Lecharny wrote:
> On 8/26/11 6:03 PM, Alan D. Cabrera wrote:
>> On Aug 26, 2011, at 8:12 AM, Emmanuel Lecharny wrote:
>>
>>> On 8/26/11 4:55 PM, Alan D. Cabrera wrote:
>>>> On Aug 26, 2011, at 7:47 AM, Emmanuel Lecharny wrote:
>>>>
>>>>> On 8/26/11 4:28 PM, Alan D. Cabrera wrote:
>>>>>> On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
>>>>>>
>>>>>>> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny<[email protected]>
>>>>>>> wrote:
>>>>>>>> On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
>>>>>>>>> On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
>>>>>>>>>
>>>>>>>>>> On Fri, Aug 26, 2011 at 3:24 PM, Alan D.
>>>>>>>>>> Cabrera<[email protected]>
>>>>>>>>>> wrote:
>>>>>>>>>>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>>>>>>>>>>>
>>>>>>>>>>>> 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);
>>>>>>>>>>>>
>>>>>>>>>>>> acceptor.bind(...);
>>>>>>>>>>> How do we make chains where two filters feed into one or one filter
>>>>>>>>>>> feeds two filters? If you look in my sandbox we can accommodate
>>>>>>>>>>> this via:
>>>>>>>>>>>
>>>>>>>>>>> static import a.m.util.Util. linkParentWithChild; // to be written
>>>>>>>>>>>
>>>>>>>>>>> IoFilter foo = new FooFilter();
>>>>>>>>>>> LinkStateFilter link = new LinkStateFilter();
>>>>>>>>>>> IoFilter checksum = new ChecksumFilter();
>>>>>>>>>>> IoFilter log = new LogFilter();
>>>>>>>>>>>
>>>>>>>>>>> link.addLinkStateListener(foo);
>>>>>>>>>>> linkParentWithChild(foo, checksum);
>>>>>>>>>>> linkParentWithChild(link, checksum);
>>>>>>>>>>> linkParentWithChild(checksum, log);
>>>>>>>>>>>
>>>>>>>>>>> acceptor.setFilters(foo);
>>>>>>>>>>>
>>>>>>>>>> About the code in the sandbox :
>>>>>>>>>>
>>>>>>>>>> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
>>>>>>>>>> I see no IoFilter.addLinkStateListener(..) method, am I looking at
>>>>>>>>>> the
>>>>>>>>>> right place ?
>>>>>>>>> Oops, it was meant to just be a sketch. :)
>>>>>>>>>
>>>>>>>>>> About the "filters feed into one or one filter feeds two filters", do
>>>>>>>>>> you have a concrete use case in mind for that ?
>>>>>>>>> The above example does, Foo and the link state filter. I'm sure that
>>>>>>>>> we've discussed this before. Another example is a mux/demux
>>>>>>>>> situation. How
>>>>>>>>> would all of this fit into the grand scheme of things?
>>>>>>>> Yeah, it really should be a graph of filters, not a list of filters.
>>>>>>>>
>>>>>>> Well if it's just for demuxing I proposed few mails ago this solution
>>>>>>> : http://s.apache.org/A9W
>>>>>> I think we need to make graphing a 1st class citizen and not buried
>>>>>> inside another filter class.
>>>>> I do agree. The proposed solution on http://s.apache.org/A9W is what we
>>>>> currently have, and it's tedious to manage.
>>>>>
>>>>> It would be way better to be able to let the controler call the next
>>>>> filter based on an evaluation method based on the current state.
>>>>>
>>>>>
>>>>> Now, the question is : how do the controller knows which filter to call
>>>>> next ? It must have the current state, and it must be able to make the
>>>>> connection.
>>>>>
>>>>> For instance, let's say that from filter F we can switch to either filter
>>>>> G or filter H, depending on the state we transit to in F.
>>>>>
>>>>> F --(state1)--> G
>>>>> or
>>>>> F --(state2)--> H
>>>>>
>>>>> That means the controller has a map { (F, state1, G), (F, state2, H)}
>>>>> somewhere. State should be passed to the controller too :
>>>>>
>>>>> ...
>>>>> controller.nextFilter( newState );
>>>>> ...
>>>>>
>>>>> Pretty theorical at this point... I'm sorry not to have a lot of time to
>>>>> code this, I do realize that for you guys implementing ideas it's a
>>>>> PITA...
>>>> I was thinking of a simple DAG some, or all, of the nodes can be FSMs.
>>>>
>>>> -> [FSM1] -> [Filter] -> [FSM2] -> [Filter]
>>>>
>>>> Inside the FSM there could be chains, but there would be one chain per
>>>> state.
>>> Not sure I grok what you say here. There is more than one state, and from
>>> each state, you may have more than one transition.
>>>
>>> Maybe it's just a problem of vocabulary...
>>>
>>> <theory>
>>> In a FSM, you transit from Si to Sj, following a transition Ta, which
>>> depends on a context. You may also transit to a state Sk, following a
>>> different transition Tb, if the context is different.
>>>
>>> Selection the transition to follow is all about knowing what's the context
>>> is, and in my sample, this was what I call the 'state', which was most
>>> certainly an error, as it's clearly a transition. I should have wrote :
>>>
>>> F --(transition1)--> G
>>> or
>>> F --(transition2)--> H
>>>
>>> where F, G, H are filters (ore "states")
>>>
>>> are we on the same page ?
>>>
>>> </theory>
>> Not at all. :)
>>
>> Are F, G, H filters inside the FSM or are they external to the FSM?
>
> They are filters in the FSM.
Ok, now I know where you're coming from. For me I have a map of chains
Map<State, Chain> states = …
State current;
void send(T message)
{
Chain chain = states.get(current);
current = chain.send(message);
}
So the effect is
[outside filter] -> [FSM [current chain] ] -> [outside filter]
