> Emmanuel Lecharny [mailto:[EMAIL PROTECTED] wrote:
>
> Hi guys,
Hi!
> here are some thoughts and ideas I have had those last few days,
> thoughts that I have experimented in branches. It's not finished yet,
> but I think I have something likely to work well and be easier to use
> than the current implementation.
>
> So here are the gathered thoughts, please feel free to give me feedback
> :
>
>
> Refactoring the current chain : possible implementations
[snip]
> ---------------------------------------------------------
>
> 2) Proposed solutions
> ---------------------
>
[snip]
In my opinion, the 2.1 and 2.2 solution is nearly the same, just the way you
iterate the filter is different:
2.1: Iterations outside of the filter (Con: no pre/post processing)
2.3: Index based iteration inside the filter (Con: looks ugly to me ;-),
indices aren't safe if you use ExecutorFilter)
2.2 is somewhat different: You're using a simple kind of LinkedList and pass
the current filter the entry of the "next" element
>
> 3) Choice
> ---------
>
> If we cant to keep all the existing functionalites MINA has, solution
> 2.3 is obviously the way to go. Well implemented, it will also be fast
> and easy to debug, and, last, not least, it's close to what we curently
> have, but with less code and a better interface.
I think a combination of the three would be good:
An Iterator like object is passed to the Filter:
processEventXXX(message, chainIterator){
//preprocessing
chainIterator.next().processEventXXX()
//postprocessing
}
This way you don't need to deal witch an index.
If the data the Iterator is based of is immutable, synchronization isn't
needed. Just replace the data and the next created iterator will use it.
Pro:
No need for ugly and unsage indices
No need to decide wich way to iterate the list, bottom-up or top-down are
handled by different iterators
Synchronisation isn't needed
Pre and post processing
easy usage, easy implementation
Con:
overhead for iterator creation ?
regards
Steve
