Mailing-List: contact dev-help@mina.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@mina.apache.org
Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com
 designates 209.85.219.212 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=jvIHm09CkvVpYOCeO6GZ/foPQ6PO0M6uR2ilhs169mw/FXVw0O6DvS7NvuUJb+mFPC
         +7zDRR4LlumV+Xo6yFHhJvd9satCUI0EZqc7j6isstmE9dq36Oc0LT62d8v6SiFcvLUY
         K7vCzUosVLLKncgm46S6FlQ3Aj+Gr067IOE+8=
Message-ID: <4B24CDB2.3040405@gmail.com>
Date: Sun, 13 Dec 2009 12:19:14 +0100
From: =?UTF-8?B?RW1tYW51ZWwgTMKOY2hhcm55?= <elecharny@gmail.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: dev@mina.apache.org
Subject: Re: [MINA 3.0] Initial thoughts on FilterChain
References: <f404ff2d0911260225q4d64c3aj69ecb85d76f1cd0c@mail.gmail.com>
 <d45b08f00911270926g4bdc7f21i8d8f3d511e9e9936@mail.gmail.com>
 <f404ff2d0911272023g45c1736axe7771045f48a048@mail.gmail.com>
 <4A83411F-47C5-4E75-B412-2BE2FB91093B@toolazydogs.com>
 <f404ff2d0911280232t1ccdede9qd767e12016c71ed6@mail.gmail.com>
 <ABF911DB-7088-4E26-9A41-7DA3D893623A@toolazydogs.com>
 <f404ff2d0911281803u2e8eff02v28a5b10179910515@mail.gmail.com>
 <1158D10C-1610-449C-8DC2-E6921F7A7886@toolazydogs.com>
 <f404ff2d0912030308j4cd69184t1db39acd974a11eb@mail.gmail.com>
 <A13874EB-0898-46C7-A0EC-FE101F76EF47@toolazydogs.com>
 <f404ff2d0912031728ma9eb502lf27cd6aced1a1c8b@mail.gmail.com>
 <331FC8CB-3DD8-4FA0-B4AA-D978ECE604E0@toolazydogs.com>
In-Reply-To: <331FC8CB-3DD8-4FA0-B4AA-D978ECE604E0@toolazydogs.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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
>
>
>