To add something to my previous reply, there is one case where the
'chain' can be dynamically modified : when adding the LoggingFilter for
debugging purposes. I guess we can think about some other user czses, by
IMO, they are not so frequent. MINAOP ? ;)
Alan D. Cabrera a écrit :
>
> On Dec 3, 2009, at 5:28 PM, Ashish wrote:
>
>>>>> What about the assertion that new filters only get created to
>>>>> simulate a
>>>>> state machine?
>>>>
>>>> Finally, managed to check-in some of the initial thoughts.
>>>> The transition handler or the computeNext function is still to be
>>>> out in.
>>>
>>> Sorry. Not sure how that answers my question other than to detail what
>>> you've done and what you're about to do.
>>>
>>
>> OOPS! :-( I think I am getting old
>>
>> After a discussion we thought that we shall make it possible for
>> user's to choose the way we want Filter transitions
>> That's what the transition handler is :-) Default implementation shall
>> be of next Filter in the chain.
>> User's can plugin their implementations for transition say like a
>> State Machine implementation.
>>
>> Since I couldn't take it to logical conclusion, still working on it :)
>> Also my experience with State machines is limited, so will need a
>> helping hand here (or may be some references :-) )
>
> The key thing about state machines is that the states and the
> transitions are known and fixed ahead of time. If this our state of
> affairs, and I think that it is, then things are much more simple and
> mentally tractable, i.e. there's no ad hoc filter creation during
> protocol processing and much of the threading issues in past entries
> on this thread disappear.
>
>
> Regards,
> Alan
>
>
>
|