On Aug 26, 2011, at 9:15 AM, Julien Vermillard wrote:
> 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.
If you think it's useful to work out lower level details while the API design
is still happening, cool. It may happen that decisions about the API will
affect your work. With that said, I think that it would be interesting to see
what can be done for an NIO loop that is different from the existing Mina ones.
Regards,
Alan
