>  I thought IoFilter.init(IoFilterchain, NextFilter, IoSession) makes sense instead.  Am I missing something? :) 
 
The only problem here is that it implies that the filter always has a session after it has been init'ed.
For shared filters this may not be the case (for example, a port filter would be init'ed at first use, but that doesn't mean it'll always have any sessions to talk to).
 
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.

Filters would never be inited until a session comes along.
My proposal does have a problem though: A shared (acceptor / port)
filter would only be inited / destroyed once (not per session) because
it's the NextFilter that contains the smarts (not the filter).
It means that per session init / destroy logic should come in
"sessionCreated" / "sessionDestroyed" and not "init".
"init" / "destroy" would be used for initialisation / tear-down of the
filter itself (e.g. acquiring / releasing resources).

 >  I think we should delay calling init() or destroy() when it is added to per-manager or per-port chain at the moment to when it is copied to per-session chain.   
>  So we can think per-manager or per-port chain is just an *inactive* chain that provides data structure only.   
>  And I don't see any reason to call init() in manager/port level if it works only for session. 
 
What about per filter initialisation? 
I was thinking that a filter would be inited the first time it was employed (i.e, first session for acceptor filters, first session on port  for port filters, and per session for session filters).
 
Dave
 

WDYT?

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.

Reply via email to