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 <[email protected]>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
