>> Keeping
IoSession out of init (IMHO) steers implementors towards using init / destroy
for per-filter initialisation (such as obtaining resources) .
>> A
filter which wants to kick out events when a session is created can use
sessionCreated for this.
> Is this for another implementation which doesn't copy the chain, right?
Any
implementation will need a data-structure representing the chain for a
session: So I guess any implementation will have some notion of "copying the
chain".
However, what has proposed by some in the past is copying
filters themselves.
I
wasn't intending on copying filters - just building up a per session
logical chain. Each per session chain would re-use existing acceptor / port
filter instances, but would internally manage routing between them so
that the users just see a single chain from which they can add / remove / clear
/ whatever.
Trustin
what we call human nature is actually human habit
--
http://gleamynode.net/
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
