2005/11/17, Irving, Dave <[EMAIL PROTECTED]>:
IoFilter implementations should remember the parent session (or session manager) so that it's OK even if init and destroy is invoked many times and thus shared by many sessions. Please take a look at ThreadPoolFilter.init() and destroy() for example. And we cannot simply call init() once because some filters will want it to be invoked as many times as it is added.
So I think that isn't a problem. WDYT?
The smart NextFilter is a great idea, but if we can solve this issue simply, then I think it's OK for now. We're still in unstable branch, so we can change/improve it. What about waiting for some user feedback?
But I think the choice is good basically. So If you're implementing either, then we could try both and choose one. Though I think the simpler thing is the better in general. :)
> To me this issue seems to be getting increasingly complex.
> Maybe it has been suggested before but wouldn't it be possible to
define
> only the filters for a session manager and port and create the one and
only
> session chain when a new session is created?
That's the simplest and cleanest way to do it.
The only thing that worries me here is that acceptor / port filters will
be added to each and every session chain.
This means they will be "init"ed and "destroy"ed per session.
If this isn't a problem - then we can roll with the simple solution.
However, Trustin was talking about filter implementations caching their
NextFilters so that events can be propogated asyncronously (and this
gets harder for filter implementors to do when these filters are reused
in multiple sessions).
IoFilter implementations should remember the parent session (or session manager) so that it's OK even if init and destroy is invoked many times and thus shared by many sessions. Please take a look at ThreadPoolFilter.init() and destroy() for example. And we cannot simply call init() once because some filters will want it to be invoked as many times as it is added.
So I think that isn't a problem. WDYT?
My solution would have a moderately complex ** implementation ** but the
api to users would be the same as it is today, whilst keeping shared
filters only getting inited once, with a single (smart) NextFilter.
The smart NextFilter is a great idea, but if we can solve this issue simply, then I think it's OK for now. We're still in unstable branch, so we can change/improve it. What about waiting for some user feedback?
But I think the choice is good basically. So If you're implementing either, then we could try both and choose one. Though I think the simpler thing is the better in general. :)
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
