So how do we move forward with this? So far no one seems to disagree.
Should we allow tap authors more time to respond? Does someone need to
do a more thorough review code to determine if no taps do, in fact,
depend on the current display filter? Should we make a design decision
that tap listeners should not depend on the current display filter, or
a seperate function should be created (or perhaps my "retap" flag
should be replaced with something that is a bit more intelligent, and
allows only specific taps to be rebuilt if needed)?
Ian
On Jul 27, 2004, at 2:35 AM, Guy Harris wrote:
On Mon, Jul 26, 2004 at 04:18:31PM -0400, Ian Schorr wrote:
Still a bit concerned that the taps are being rebuilt when changing
display filter and other events that really should only change the
packet list, though. What if we did something simple like this (see
attached patch against latest SVN)?
That sounds reasonable *if*, in fact, refiltering the display *doesn't*
change any taps.
It looks as if "tap_push_tapped_queue()" would get called regardless of
whether the packet passes the filter or not, and the taps have their
own
filters, so, unless it's considered a bug, rather than a feature, that
the display filter has no effect on the taps, that sounds like the
right
thing to do.
