> 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?
I agree - I think its possible for filters to still dispatch events to a target chain if required. The only issue is that it pushes more work in to every filter implementation which wants to do async dispatching of events.
> So I think that isn't a problem. WDYT?
I agree - I think its possible for filters to still dispatch events to a target chain if required. The only issue is that it pushes more work in to every filter implementation which wants to do async dispatching of events.
Each (user) implementation would have to maintain its
own knowledge of parent -> NextFilter. Its no big deal - but its just a
step up in complexity for the user.
The smart-NextFilter way means the user doesn't have to do this as the framework
manages the mapping on the behalf of the user.
Any time a filter wants to generate an event, it just fires
it to the NextFilter.
So the only difference between the two approaches is "who
does the work": The user or the framework.
> 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.
:)
Cool.
Here's what I'll do then.... I'll start out implementing the "smart-NextFilter"
approach this evening after work. If it starts looking like its going to be
complex or hard to maintain, I'll drop it for now and go the easier
route.
How
does that sound?
> Cheers,
> Trustin
Dave
P.s, I
really appreciate all the time youself, Niklas and Jose have spent
providing feedback on all this....
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.
