mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Ulrich <steve.ulr...@proemion.com>
Subject RE: [Chain refactoring] Some fedback and ideas no--signature
Date Fri, 07 Nov 2008 10:00:10 GMT
> Emmanuel Lecharny [mailto:elecharny@gmail.com] 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

Mime
View raw message