> You can still write your filter below without needing to cache NextFilter. Am I wrong?
No, I think you are right. However, I think the whole "next filter" thing is actually quite nice - as it gives a proxy to enable events to carry on down stream in an async manner. Lets presume a filter writer uses your approach and looks up the next filter from the session. Theres still a race between looking up the next filter and actually using it - so we'd need a smart NextFilter to resolve this issue anyways (or we'd have to instruct filter implementations to start locking on things - which I personally don't like very much). Therefore, whether a user caches a NextFilter, or looks it up, I don't think it changes the fact that NextFilters need to be a bit smart. My proposed change will work either way. A filter can cache a "NextFilter" as a token for onward events if it chooses (which means it doesn't have to write all the look up code), ** or ** it can look up the NextFilter on demand and use it. Either way works with my proposal. Hope this is clearer... Dave 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.
