Mailing-List: contact dev-help@mina.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@mina.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Steve Ulrich <steve.ulrich@proemion.com>
To: "dev@mina.apache.org" <dev@mina.apache.org>
Date: Fri, 7 Nov 2008 11:00:10 +0100
Subject: RE: [Chain refactoring] Some fedback and ideas no--signature
Message-ID: 
 <079C41B129004A4ABAFA9562B3C0C00D023C679B29@rmsv008.rmcorp.rm-michaelides.com>
References: <4913A11F.5060107@nextury.com>
In-Reply-To: <4913A11F.5060107@nextury.com>
Content-Language: de-DE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

> 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 yo=
u 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 ;-), in=
dices aren't safe if you use ExecutorFilter)

2.2 is somewhat different: You're using a simple kind of LinkedList and pas=
s 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 ne=
eded. 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