Ethereal-dev: Re: [Ethereal-dev] moving from plugin to buildin

Note: This archive is from the project's previous web site, This list is no longer active.

From: "Guy Harris" <[email protected]>
Date: Tue, 27 Jul 2004 12:17:48 -0700 (PDT)
Erwin Rol said:
> Well the TAP-part will be build in,

Ultimately, we should support plug-in taps.

Right now, the main problem is that taps *have* to have UI code, so a
plug-in tap couldn't work with both Ethereal and Tethereal.  That also
means that we have a number of taps where there's one implementation for
Tethereal and another for Ethereal.

We've talked about a mechanism by which at least some taps could just
maintain a table containing statistics (e.g., they'd say "here's a table
with N columns, and here are the titles and data types of the columns",
and "here's a new row to add to the table" and "I'm finished adding rows
to the table"), and code in the application (Ethereal or Tethereal) would
take responsibility for printing/displaying the table.

That'd mean that

    1) we *could* add support for making those taps plugins - and could
conceivably allow a "packet-XXX.c" file to contain taps for the
protocol as well;

    2) you'd have to write less code for a tap that just generated a table
of statistics;

    3) that tap would work with Ethereal and Tethereal;

    4) it could conceivably allow you to display a table in multiple forms
from the UI (table, graphs of various sorts, etc.).

I think one of the Lars R's sent in some work he'd done on that, with a
note saying it was incomplete, and some folks at a university in Australia
were looking at a project that could result in such a mechanism.

(And for taps *with* UI code, it might be interesting to see whether
Gerald's XUL work could result in XUL being read in at run time and
providing the UI for a tap; presumably such a tap would be ignored by
Tethereal, unless the UI isn't necessary to tell the tap what to do, and
handled by an XUL interpreter for various versions of Ethereal with
various toolkits.)