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?
Regards,
Alan
