Guy Harris wrote:
> comma = strchr(optarg, ',');
I knew there had to be a function to do that... just didn't know what it was
called...
> fprintf(stderr, "tethereal: invalid -z argument: %s\n",
> error_message);
> 2) the error message isn't necessarily an error from a
> particular tap listener, it might be an error saying there *is*
> no such tap listener;
Good call... I'd probably also be tempted to output optarg as well... Does tethereal
support multiple '-z' arguments? If not something needs to get changed.
> 3) neither ... nor ... are legal C89.
Very true, but I was actually trying to get across the idea with as little side
commentary/prototyping as possible... I figured that including the type like that
would make the idea clear, even if it was invalid C (but valid C++ that most would
understand)
> > A simple window where you select a tap listener from a combo box, and have
> > one or two string inputs.
>
> Or a mechanism by which tap listeners can be added to the "Tools" menu
> (including a mechanism to add new submenus), and, when the menu item is
> selected, have a dialog box popped up to provide input to the tap and an
> optional filter expression.
Hopefully only as far as Tools->Add Tap Listener and not an entry for each tap... as
the # of taps grow, direct entry in a menu bar may become cumbersome...
> > A function to convert the
> > preferences into a tap listener configuration string would force tethereal to
> > be at least as capable as ethereal...
>
> I.e., to use the preferences to control how the stuff after the "," in
> the argument to "-z" is parsed, so that the parsing is done *outside*
> the tap itself? Sounds good.
I was actually thinking the reverse. Having the preference settings being
converted to a string for dissection *inside* the tap. Dissection of the string
completely outside of the tap does sound appealing, but I worry about what
limitations the GUI itself would impose upon the configuration capability of the
tap. Like building SQL statements graphically: the GUI makes certain things nice,
but sometimes you just need to write it out by hand.
Maybe the right approach would be for a tap to say whether or not it wants to do
dissection of its own arguments. That way *most* taps can benefit from dissection
*outside* of the tap, but then taps that allow complex configurations can do their
own custom dissection *inside* the tap.
