> (It *might* be possible to evaluate the expression as the dissection is > done, doing all the dissection work for a particular field only if that > field actually appears in a plugin's filter expression. Doing that > might also let us speed up display filtering, display searching, and > display coloring - the only time you need *all* the fields is when > you're building the detail view for display or printing.) Or, as an alternative, we could handle expressions that do an equality comparison on certain fields specially - have a "proto.c" routine that can check whether a dfilter expression checks if a particular field (specified by its name, or by its index) is equal to a constant and, if so, returns the constant, and, if the expression is, say "tcp.port == 666", we could just have TCP check for that port number (by checking in a list, or looking it up in a hash table, or...). If all of the expressions are of that type, there wouldn't be a need to construct the protocol tree when we're filling in the CList for the summary pane; if some expressons weren't of that type, we'd have to arrange to construct the protocol tree even when filling in the CList.
Powered by MHonArc 2.6.10