2005/11/17, Irving, Dave <[EMAIL PROTECTED]>:
I thought IoFilter.init(IoFilterchain, NextFilter, IoSession) makes sense instead. Am I missing something? :)
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.
IoFilter.init(IoFilterChain parent, NextFilter nextFilter) does make
sense if you want your init to fire an event.
I thought IoFilter.init(IoFilterchain, NextFilter, IoSession) makes sense instead. Am I missing something? :)
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.
WDYT?
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
