You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Ashish <pa...@gmail.com> on 2011/06/30 11:42:45 UTC
Re: [MINA 3.0] Initial thoughts on FilterChain
Fortunately was able to find this mail chain in inbox :)
reigniting the discussion again.
Was looking for something that meets our needs and landed with Commons Chain
(http://commons.apache.org/chain/)
This does meet some of our requirements, but not all. We can have something
similar to this and instead of returning true/false
from Filters, we can return the next step to be executed. Something like
this
IoFilter messageReceived(IoSession session, Object message) {
// process
// see if just to flow with Filter Chain
return null; // or something better
// or
// a diff message detected, calculate next filter based on some app
specific state
return calculateNextFilter(state);
}
command is passed back to the chain and it can take care of executing the
next filter.
Shall try something similar in sandbox and lets see how it goes :)
thanks
ashish
On Tue, Dec 15, 2009 at 9:13 PM, Alan D. Cabrera <li...@toolazydogs.com>wrote:
>
> On Dec 15, 2009, at 4:30 AM, Emmanuel LŽcharny wrote:
>
> Hi,
>>
>> there is another approach if we switch to a SM : actions don't need to
>> know about the next action, as it's computed by the SM. We can end with
>> methods like :
>>
>> messageReceived() {
>> blah
>> }
>>
>
> Yes, this is along the lines of what I was thinking.
>
>
> and when the method returns, the SM decide which filter to call next. This
>> end up with something like :
>>
>> while ( not Done ) {
>> nextFilter = computeNext(session);
>> nextFilter.messageReceived(**session);
>> }
>>
>
> This is not much better than what we had before. The chains should be
> fixed.
>
> while (!session.closed())
> {
> List<IoFilter> filters = session.getChain(session.**getState());
> for (IoFilter filter : filters) filter.messageReceived(**session);
>
> }
>
>
>> The only constraints being that we don't have code like :
>>
>> messageReceived(session) {
>> blah();
>> call next filter; // Not necessary anymore...
>> post_blah(); /// Wrong !!!
>> }
>>
>
> Yay!
>
>
> Now, why did we used Filters at the origin ? It's important to know that
>> when Alex thought about what should be MINA 6 years ago, and before Trustin
>> joined the project, the idea was to implement a SEDA based framework.
>>
>> What does it imply in real world ? Many things. First, transition between
>> one filter and another should allow the use of a queue, so interactions are
>> asynchronous. Another aspect is that we may have more than one thread
>> running on one session (some decoding can occur while a new message is being
>> received). Another consequence is that we may have unordered messages : if
>> two threads are being processed for the same session, one can be faster to
>> decode than the second one, and the second one can perfectly well hit the
>> Handler before the first one. We have some mchanism to protect the user from
>> such a problem.
>>
>> Ig we have to keep this SEDA approach, then we must be careful and be sure
>> that we can process each filter separately. looking at the loop I exposed
>> above, we will have a problem because the loop is executed sequencially by
>> one single thread, so we can't anymore implement any SEDA mechanism.
>>
>> If the filter is responsible for the call of the next filter, then it's a
>> totally different story.
>>
>> We have to think about this before drafting some implementation, and
>> decide if we want to stick to SEDA.
>>
>
> Agreed. This is something we should support. I think that the original
> complexity came from mixing concerns.
>
> What if we had channels that could contain things like queues, state
> machines, etc.? Channels would be bidirectional, i.e. messages would move
> up and down in a single channel. We would then compose channels in fixed
> DAGs.
>
>
> Now, some comment in line about Alan's last mail
>>
>> Alan D. Cabrera a écrit :
>>
>>>
>>> <Snip/>
>>>
>>>> Not sure this is possible in another way than with those computed
>>>>>> nextFilter() inside the filters.
>>>>>>
>>>>>
>>>>> I agree but it's my contention that it's a bad practice that supports
>>>>> an ill thought out protocol.
>>>>>
>>>>
>>>> The biggest advantage is that it eases the implementor work most of the
>>>> cases.
>>>>
>>>
>>> IMO, it's sloppy and error prone and obfuscates code. If no one else
>>> agrees then I'm happy to drop my point.
>>>
>> You are probably right. If you look at the existing filters, there is no
>> reason we should not be able to avoid such code.
>>
>>
>>> Now, it does not preclude that we should not allow someone to implement
>>>> his protocol using a complete state machine. May be we should provide both
>>>> mechanisms :
>>>> - one which is driven by the code (ie, the code 'pull' the next step),
>>>> - one which is driven by the state machine (your way).
>>>>
>>>
>>> I would argue against this. Mina is afflicted w/ bloat.
>>>
>> I can't agree more :)
>>
>> One the goals should be to get rid of as many useless "helpful" classes
>>> and methods as we can.
>>>
>> +1
>>
>> Either we all agree that adding filters in an ad hoc manner is a best
>>> practice for network protocol state machines and we loose the state machine
>>> or we agree that it's an anti-pattern that should be avoided. If the
>>> community thinks that ad hoc filters are a best practice I'm happy to drop
>>> my point.
>>>
>> I would like to keep the SM approach, but as explained above (SEDA thing),
>> I think we should be driven by the code.
>>
>> <snip/>
>>>
>>> I totally agree with this approach to deciding on the API and am happy to
>>> help out w/ some protocols, e.g. HTTP and SSL.
>>>
>>> I am curious, what project feels that it needs to do an "implicit" state
>>> machine? I would love to take a peek at the code.
>>>
>> What do you mean by "implicit" state machine ?
>>
>
> In the "ad hoc" state transition approach the state transitions are
> implicit in the code rather than explicit and fixed in a set of data
> structures. To understand the implicit state machine one must carefully
> read all the code to understand what's going on.
>
>
> Regards,
> Alan
>
>
>
--
thanks
ashish
Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [MINA 3.0] Initial thoughts on FilterChain
Posted by Julien Vermillard <jv...@gmail.com>.
On Fri, Jul 1, 2011 at 5:58 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> On Jul 1, 2011, at 8:52 AM, Emmanuel Lecharny wrote:
>
>> On 7/1/11 5:47 PM, Alan D. Cabrera wrote:
>>> On Jul 1, 2011, at 8:04 AM, Emmanuel Lecharny wrote:
>>>> But all in all, in this case, the chain of filters will *be* a state machine.
>>> And here is my point. They all are really state machines. Having network protocols "randomly" choosing chain paths is an anti-pattern. State machines should be known and fixed at the time of protocol initiation.
>>
>> Don't get me wrong... I'm not sure anyone here had in mind an implementation which picks the next filter randomly... Although, that could be funny :)
>
> To everyone but the person who has to debug what's going on. ;)
>
> With that said, why would we want our API make that possible? Would we not be doing our user base a service by switching the Mina API to a bona fide state machine with fixed state chains?
>
>
> Regards,
> Alan
>
Hi,
I think it's possible to make FilterChain a simple List of Filters
called by the chain and not-chained as we do.
For special usage where the Filter decide which filter to call, the
filter could be called from the "demuxing" filter :
http://s.apache.org/A9W
The chain could be stored in the IoService and copied to the session
only if it specifically was modified for this session (Copy on write).
It could save some memory.
Now the *REAL QUESTION* is how we implement SEDA/ExecutorFilter with
this kind of list of filter ?
Julien
Re: [MINA 3.0] Initial thoughts on FilterChain
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 1, 2011, at 8:52 AM, Emmanuel Lecharny wrote:
> On 7/1/11 5:47 PM, Alan D. Cabrera wrote:
>> On Jul 1, 2011, at 8:04 AM, Emmanuel Lecharny wrote:
>>> But all in all, in this case, the chain of filters will *be* a state machine.
>> And here is my point. They all are really state machines. Having network protocols "randomly" choosing chain paths is an anti-pattern. State machines should be known and fixed at the time of protocol initiation.
>
> Don't get me wrong... I'm not sure anyone here had in mind an implementation which picks the next filter randomly... Although, that could be funny :)
To everyone but the person who has to debug what's going on. ;)
With that said, why would we want our API make that possible? Would we not be doing our user base a service by switching the Mina API to a bona fide state machine with fixed state chains?
Regards,
Alan
Re: [MINA 3.0] Initial thoughts on FilterChain
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 7/1/11 5:47 PM, Alan D. Cabrera wrote:
> On Jul 1, 2011, at 8:04 AM, Emmanuel Lecharny wrote:
>> But all in all, in this case, the chain of filters will *be* a state machine.
> And here is my point. They all are really state machines. Having network protocols "randomly" choosing chain paths is an anti-pattern. State machines should be known and fixed at the time of protocol initiation.
Don't get me wrong... I'm not sure anyone here had in mind an
implementation which picks the next filter randomly... Although, that
could be funny :)
>> I have some ideas (and I even have created some branch years ago: http://svn.apache.org/viewvc/mina/branches/mina-new-chain/ and http://svn.apache.org/viewvc/mina/branches/mina-new-chain2/) to play around this idea.
> I'll take a peek at these. Thanks!
frankly, those branches are mostly errands at this point. Don't expect
too much...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] Initial thoughts on FilterChain
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 1, 2011, at 8:04 AM, Emmanuel Lecharny wrote:
> On 7/1/11 4:59 PM, Alan D. Cabrera wrote:
>> On Jun 30, 2011, at 4:13 PM, Emmanuel Lecharny wrote:
>>
>>> On 6/30/11 9:52 PM, Alan D. Cabrera wrote:
>>>> On Jun 30, 2011, at 2:42 AM, Ashish wrote:
>>>>
>>>>> <snip/>
>>>>> This does meet some of our requirements, but not all. We can have something
>>>>> similar to this and instead of returning true/false
>>>>> from Filters, we can return the next step to be executed. Something like
>>>>> this
>>>>>
>>>>> IoFilter messageReceived(IoSession session, Object message) {
>>>>> // process
>>>>>
>>>>> // see if just to flow with Filter Chain
>>>>> return null; // or something better
>>>>>
>>>>> // or
>>>>> // a diff message detected, calculate next filter based on some app
>>>>> specific state
>>>>> return calculateNextFilter(state);
>>>>> }
>>>>>
>>>>> command is passed back to the chain and it can take care of executing the
>>>>> next filter.
>>>>>
>>>>> Shall try something similar in sandbox and lets see how it goes :)
>>>> I'm not so sure that filters should be in charge of deciding who should be called next. I don't think that how the filter stack is assembled should be leaked into the filters themselves. The filter should be solely concerned with its task and not have to decide who gets called next.
>>> Not sure, Alan. There are some cases where it's mandatory that a filter select the next filter to execute : for instance, if your codec produces more than one message, and the following processing may depend on the message type. Of course, you can use a demux protocol filter (I don't exactly remember the name of it, so it's from the top of my head, but we use such a mechanism in ADS), but it's just one option.
>>
>> I'm hearing a state machine that's implicitly defined via what gets returned by that method. If this is the case would it not be better to have an explicitly defined state machine?
>
> Not necessarily. We can think about a multiple layer decoder which works the very same way.
I'm hearing possibility not necessity.
> But all in all, in this case, the chain of filters will *be* a state machine.
And here is my point. They all are really state machines. Having network protocols "randomly" choosing chain paths is an anti-pattern. State machines should be known and fixed at the time of protocol initiation.
> I have some ideas (and I even have created some branch years ago: http://svn.apache.org/viewvc/mina/branches/mina-new-chain/ and http://svn.apache.org/viewvc/mina/branches/mina-new-chain2/) to play around this idea.
I'll take a peek at these. Thanks!
Regards,
Alan
Re: [MINA 3.0] Initial thoughts on FilterChain
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 7/1/11 4:59 PM, Alan D. Cabrera wrote:
> On Jun 30, 2011, at 4:13 PM, Emmanuel Lecharny wrote:
>
>> On 6/30/11 9:52 PM, Alan D. Cabrera wrote:
>>> On Jun 30, 2011, at 2:42 AM, Ashish wrote:
>>>
>>>> <snip/>
>>>> This does meet some of our requirements, but not all. We can have something
>>>> similar to this and instead of returning true/false
>>>> from Filters, we can return the next step to be executed. Something like
>>>> this
>>>>
>>>> IoFilter messageReceived(IoSession session, Object message) {
>>>> // process
>>>>
>>>> // see if just to flow with Filter Chain
>>>> return null; // or something better
>>>>
>>>> // or
>>>> // a diff message detected, calculate next filter based on some app
>>>> specific state
>>>> return calculateNextFilter(state);
>>>> }
>>>>
>>>> command is passed back to the chain and it can take care of executing the
>>>> next filter.
>>>>
>>>> Shall try something similar in sandbox and lets see how it goes :)
>>> I'm not so sure that filters should be in charge of deciding who should be called next. I don't think that how the filter stack is assembled should be leaked into the filters themselves. The filter should be solely concerned with its task and not have to decide who gets called next.
>> Not sure, Alan. There are some cases where it's mandatory that a filter select the next filter to execute : for instance, if your codec produces more than one message, and the following processing may depend on the message type. Of course, you can use a demux protocol filter (I don't exactly remember the name of it, so it's from the top of my head, but we use such a mechanism in ADS), but it's just one option.
>
> I'm hearing a state machine that's implicitly defined via what gets returned by that method. If this is the case would it not be better to have an explicitly defined state machine?
Not necessarily. We can think about a multiple layer decoder which works
the very same way.
But all in all, in this case, the chain of filters will *be* a state
machine.
I have some ideas (and I even have created some branch years ago:
http://svn.apache.org/viewvc/mina/branches/mina-new-chain/ and
http://svn.apache.org/viewvc/mina/branches/mina-new-chain2/) to play
around this idea.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] Initial thoughts on FilterChain
Posted by Alex Karasulu <ak...@apache.org>.
On Fri, Jul 1, 2011 at 5:59 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> On Jun 30, 2011, at 4:13 PM, Emmanuel Lecharny wrote:
>
>> On 6/30/11 9:52 PM, Alan D. Cabrera wrote:
>>> On Jun 30, 2011, at 2:42 AM, Ashish wrote:
>>>
>>>> <snip/>
>>
>>>> This does meet some of our requirements, but not all. We can have something
>>>> similar to this and instead of returning true/false
>>>> from Filters, we can return the next step to be executed. Something like
>>>> this
>>>>
>>>> IoFilter messageReceived(IoSession session, Object message) {
>>>> // process
>>>>
>>>> // see if just to flow with Filter Chain
>>>> return null; // or something better
>>>>
>>>> // or
>>>> // a diff message detected, calculate next filter based on some app
>>>> specific state
>>>> return calculateNextFilter(state);
>>>> }
>>>>
>>>> command is passed back to the chain and it can take care of executing the
>>>> next filter.
>>>>
>>>> Shall try something similar in sandbox and lets see how it goes :)
>>> I'm not so sure that filters should be in charge of deciding who should be called next. I don't think that how the filter stack is assembled should be leaked into the filters themselves. The filter should be solely concerned with its task and not have to decide who gets called next.
>>
>> Not sure, Alan. There are some cases where it's mandatory that a filter select the next filter to execute : for instance, if your codec produces more than one message, and the following processing may depend on the message type. Of course, you can use a demux protocol filter (I don't exactly remember the name of it, so it's from the top of my head, but we use such a mechanism in ADS), but it's just one option.
>
>
> I'm hearing a state machine that's implicitly defined via what gets returned by that method. If this is the case would it not be better to have an explicitly defined state machine?
For simple cases this might "seem" like overkill but IMHO I think it's
better always to be explicit. It's clear what is happening. Surprise
Emmanuel that you did not jump for this you are Mr. State Machine :-).
Regards,
Alex
Re: [MINA 3.0] Initial thoughts on FilterChain
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jun 30, 2011, at 4:13 PM, Emmanuel Lecharny wrote:
> On 6/30/11 9:52 PM, Alan D. Cabrera wrote:
>> On Jun 30, 2011, at 2:42 AM, Ashish wrote:
>>
>>> <snip/>
>
>>> This does meet some of our requirements, but not all. We can have something
>>> similar to this and instead of returning true/false
>>> from Filters, we can return the next step to be executed. Something like
>>> this
>>>
>>> IoFilter messageReceived(IoSession session, Object message) {
>>> // process
>>>
>>> // see if just to flow with Filter Chain
>>> return null; // or something better
>>>
>>> // or
>>> // a diff message detected, calculate next filter based on some app
>>> specific state
>>> return calculateNextFilter(state);
>>> }
>>>
>>> command is passed back to the chain and it can take care of executing the
>>> next filter.
>>>
>>> Shall try something similar in sandbox and lets see how it goes :)
>> I'm not so sure that filters should be in charge of deciding who should be called next. I don't think that how the filter stack is assembled should be leaked into the filters themselves. The filter should be solely concerned with its task and not have to decide who gets called next.
>
> Not sure, Alan. There are some cases where it's mandatory that a filter select the next filter to execute : for instance, if your codec produces more than one message, and the following processing may depend on the message type. Of course, you can use a demux protocol filter (I don't exactly remember the name of it, so it's from the top of my head, but we use such a mechanism in ADS), but it's just one option.
I'm hearing a state machine that's implicitly defined via what gets returned by that method. If this is the case would it not be better to have an explicitly defined state machine?
Regards,
Alan
Re: [MINA 3.0] Initial thoughts on FilterChain
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 6/30/11 9:52 PM, Alan D. Cabrera wrote:
> On Jun 30, 2011, at 2:42 AM, Ashish wrote:
>
>> <snip/>
>> This does meet some of our requirements, but not all. We can have something
>> similar to this and instead of returning true/false
>> from Filters, we can return the next step to be executed. Something like
>> this
>>
>> IoFilter messageReceived(IoSession session, Object message) {
>> // process
>>
>> // see if just to flow with Filter Chain
>> return null; // or something better
>>
>> // or
>> // a diff message detected, calculate next filter based on some app
>> specific state
>> return calculateNextFilter(state);
>> }
>>
>> command is passed back to the chain and it can take care of executing the
>> next filter.
>>
>> Shall try something similar in sandbox and lets see how it goes :)
> I'm not so sure that filters should be in charge of deciding who should be called next. I don't think that how the filter stack is assembled should be leaked into the filters themselves. The filter should be solely concerned with its task and not have to decide who gets called next.
Not sure, Alan. There are some cases where it's mandatory that a filter
select the next filter to execute : for instance, if your codec produces
more than one message, and the following processing may depend on the
message type. Of course, you can use a demux protocol filter (I don't
exactly remember the name of it, so it's from the top of my head, but we
use such a mechanism in ADS), but it's just one option.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] Initial thoughts on FilterChain
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jun 30, 2011, at 2:42 AM, Ashish wrote:
> Fortunately was able to find this mail chain in inbox :)
>
> reigniting the discussion again.
>
> Was looking for something that meets our needs and landed with Commons Chain
> (http://commons.apache.org/chain/)
>
> This does meet some of our requirements, but not all. We can have something
> similar to this and instead of returning true/false
> from Filters, we can return the next step to be executed. Something like
> this
>
> IoFilter messageReceived(IoSession session, Object message) {
> // process
>
> // see if just to flow with Filter Chain
> return null; // or something better
>
> // or
> // a diff message detected, calculate next filter based on some app
> specific state
> return calculateNextFilter(state);
> }
>
> command is passed back to the chain and it can take care of executing the
> next filter.
>
> Shall try something similar in sandbox and lets see how it goes :)
I'm not so sure that filters should be in charge of deciding who should be called next. I don't think that how the filter stack is assembled should be leaked into the filters themselves. The filter should be solely concerned with its task and not have to decide who gets called next.
Regards,
Alan
>
> thanks
> ashish
>
> On Tue, Dec 15, 2009 at 9:13 PM, Alan D. Cabrera <li...@toolazydogs.com>wrote:
>
>>
>> On Dec 15, 2009, at 4:30 AM, Emmanuel LŽcharny wrote:
>>
>> Hi,
>>>
>>> there is another approach if we switch to a SM : actions don't need to
>>> know about the next action, as it's computed by the SM. We can end with
>>> methods like :
>>>
>>> messageReceived() {
>>> blah
>>> }
>>>
>>
>> Yes, this is along the lines of what I was thinking.
>>
>>
>> and when the method returns, the SM decide which filter to call next. This
>>> end up with something like :
>>>
>>> while ( not Done ) {
>>> nextFilter = computeNext(session);
>>> nextFilter.messageReceived(**session);
>>> }
>>>
>>
>> This is not much better than what we had before. The chains should be
>> fixed.
>>
>> while (!session.closed())
>> {
>> List<IoFilter> filters = session.getChain(session.**getState());
>> for (IoFilter filter : filters) filter.messageReceived(**session);
>>
>> }
>>
>>
>>> The only constraints being that we don't have code like :
>>>
>>> messageReceived(session) {
>>> blah();
>>> call next filter; // Not necessary anymore...
>>> post_blah(); /// Wrong !!!
>>> }
>>>
>>
>> Yay!
>>
>>
>> Now, why did we used Filters at the origin ? It's important to know that
>>> when Alex thought about what should be MINA 6 years ago, and before Trustin
>>> joined the project, the idea was to implement a SEDA based framework.
>>>
>>> What does it imply in real world ? Many things. First, transition between
>>> one filter and another should allow the use of a queue, so interactions are
>>> asynchronous. Another aspect is that we may have more than one thread
>>> running on one session (some decoding can occur while a new message is being
>>> received). Another consequence is that we may have unordered messages : if
>>> two threads are being processed for the same session, one can be faster to
>>> decode than the second one, and the second one can perfectly well hit the
>>> Handler before the first one. We have some mchanism to protect the user from
>>> such a problem.
>>>
>>> Ig we have to keep this SEDA approach, then we must be careful and be sure
>>> that we can process each filter separately. looking at the loop I exposed
>>> above, we will have a problem because the loop is executed sequencially by
>>> one single thread, so we can't anymore implement any SEDA mechanism.
>>>
>>> If the filter is responsible for the call of the next filter, then it's a
>>> totally different story.
>>>
>>> We have to think about this before drafting some implementation, and
>>> decide if we want to stick to SEDA.
>>>
>>
>> Agreed. This is something we should support. I think that the original
>> complexity came from mixing concerns.
>>
>> What if we had channels that could contain things like queues, state
>> machines, etc.? Channels would be bidirectional, i.e. messages would move
>> up and down in a single channel. We would then compose channels in fixed
>> DAGs.
>>
>>
>> Now, some comment in line about Alan's last mail
>>>
>>> Alan D. Cabrera a écrit :
>>>
>>>>
>>>> <Snip/>
>>>>
>>>>> Not sure this is possible in another way than with those computed
>>>>>>> nextFilter() inside the filters.
>>>>>>>
>>>>>>
>>>>>> I agree but it's my contention that it's a bad practice that supports
>>>>>> an ill thought out protocol.
>>>>>>
>>>>>
>>>>> The biggest advantage is that it eases the implementor work most of the
>>>>> cases.
>>>>>
>>>>
>>>> IMO, it's sloppy and error prone and obfuscates code. If no one else
>>>> agrees then I'm happy to drop my point.
>>>>
>>> You are probably right. If you look at the existing filters, there is no
>>> reason we should not be able to avoid such code.
>>>
>>>
>>>> Now, it does not preclude that we should not allow someone to implement
>>>>> his protocol using a complete state machine. May be we should provide both
>>>>> mechanisms :
>>>>> - one which is driven by the code (ie, the code 'pull' the next step),
>>>>> - one which is driven by the state machine (your way).
>>>>>
>>>>
>>>> I would argue against this. Mina is afflicted w/ bloat.
>>>>
>>> I can't agree more :)
>>>
>>> One the goals should be to get rid of as many useless "helpful" classes
>>>> and methods as we can.
>>>>
>>> +1
>>>
>>> Either we all agree that adding filters in an ad hoc manner is a best
>>>> practice for network protocol state machines and we loose the state machine
>>>> or we agree that it's an anti-pattern that should be avoided. If the
>>>> community thinks that ad hoc filters are a best practice I'm happy to drop
>>>> my point.
>>>>
>>> I would like to keep the SM approach, but as explained above (SEDA thing),
>>> I think we should be driven by the code.
>>>
>>> <snip/>
>>>>
>>>> I totally agree with this approach to deciding on the API and am happy to
>>>> help out w/ some protocols, e.g. HTTP and SSL.
>>>>
>>>> I am curious, what project feels that it needs to do an "implicit" state
>>>> machine? I would love to take a peek at the code.
>>>>
>>> What do you mean by "implicit" state machine ?
>>>
>>
>> In the "ad hoc" state transition approach the state transitions are
>> implicit in the code rather than explicit and fixed in a set of data
>> structures. To understand the implicit state machine one must carefully
>> read all the code to understand what's going on.
>>
>>
>> Regards,
>> Alan
>>
>>
>>
>
>
> --
> thanks
> ashish
>
> Blog: http://www.ashishpaliwal.com/blog
> My Photo Galleries: http://www.pbase.com/ashishpaliwal