> A thought I had would be for their to be a new set of routines that would
> allow any dissectors to extend the preferences dialog with additional
> requested information.
Yes, I'd been thinking along those lines.
For example, that could be used to specify, for a dissector, a filter
expression, and a parent or child protocol, to say either
any parent-protocol packet that matches this filter
should be dissected with this dissector;
any packet that matches this filter should be passed on
to the child-protocol dissector.
I.e., turn Olivier's mechanism for plugin protocols into a mechanism for
plugin *and* builtin protocols.
(If we decide that, in addition to the general mechanism, a "fast path"
for specifying "these UDP ports should be dissected as RTCP" or "these
TCP ports should be dissected as HTTP" or "this ATM VCI/VPI pair should
be dissected as Ethernet LANE" or... should also be provided - that
might not only obviate the need to build the protocol tree in many
cases, it also might offer a simpler user interface for the common case
- that'd go there as well.)
Other options might be:
for Q.931 (and Q.2931?), providing a way to specify which
particular dialect is being used (national dialects, EuroISDN or
whatever it's called, etc.);
any *other* situation where, in order to dissect a trace,
Ethereal needs more information than what it can intuit from the
packets themselves.
