> Here is the design I started working on :
> The plugin is a shared object file, which must provide :
> - string constants :
> - name : the plugin name
> - desc : a description
> - protocol : the name of the underlying protocol
> - filter_string : string using dfilter syntax. Describes the packets
> which the plugin's dissector should be called
...presumably requiring, that the protocol tree *always* be constructed,
even when only building the summary display, so that the display filter
can be evaluated.
That could make the process of reading in a capture file and building
the summary list more expensive.
(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.)
In addition, one might have a dissector where there's no dfilter syntax
to specify that - instead, you might have to look at the payload of the
underlying protocol to see whether it's a packet of that type or not
(e.g., ONC RPC, GIOP, and the Yahoo Messenger protocols).
