On Fri, Aug 26, 2011 at 6:10 PM, Emmanuel Lecharny <elecha...@gmail.com> 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<elecha...@gmail.com> 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<l...@toolazydogs.com>
>>>>>>>>>> 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.
>
Until your minds are clear about where to go about muxing,FSM and
filters I'll continue low-level implementation of MINA 3.0. The actual
filter chain is enough for me to do protocol implementation and perf
testing the NIO loops.
Julien
