mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [Chain refactoring] Some fedback and ideas no--signature
Date Fri, 07 Nov 2008 11:01:30 GMT
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



Mime
View raw message