RE: [Chain refactoring] Some fedback and ideas no--signature

[Steve Ulrich <st...@proemion.com>]

> 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

Re: [Chain refactoring] Some fedback and ideas no--signature

[Emmanuel Lecharny <el...@gmail.com>]

Steve Ulrich wrote:
>> 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.
>   
That's an excellent idea ! I will have to create a third branch to do 
that... I must admit that having to increment the index when switching 
from one filter to another is, well, ugly ?
> If the data the Iterator is based of is immutable, 
This is not the case. But the iterator may use internally a list which 
will be protected. Using a CoWAL, this is just fine.
> 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
>   

Thanks Steve !

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org