Re: [ethereal-dev] plugins support

[Guy Harris <gharris@xxxxxxxxxxxx>]

> 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).