Ethereal-dev: Re: [Ethereal-dev] plugin + tap

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

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Fri, 5 Dec 2003 13:31:05 -0800

On Dec 4, 2003, at 5:52 PM, Erwin Rol wrote:

I am making some statistics window for Art-Net and was wondering if that
is even possible in a plugin ?

Hmm.

Currently, we have no mechanism to support plugin taps, but I think that should be a goal.

It *might* be possible now to have a tap as part of a plugin dissector module, although we currently don't export the tap-registration routines, and I don't know whether you'd be able to call them in either of a dissector's registration routines or not (i.e., I don't know whether, when either the first-pass registration or second-pass registration-handoff routines are called, the tap infrastructure is set up enough to allow that).

In addition, a plugin dissector can't use any GUI code, unless you don't plan to use Tethereal (or, at least, don't plan to use that dissector with Tethereal).

I think most statistics taps should, ultimately, not have to have *any* GUI code - there should be a way for a statistics tap to register itself and handle only the statistics-gathering part, and let Tethereal common code print the results and Ethereal common code display them.

For now, you could have a plugin dissector and a non-plugin tap - that's how the MGCP statistics tap works.

And than I started to wonder what good a plugin (compared to a static
dissector) is in the first place. The only advantage i find is that it
is easier to compile and test since you can do a "make install" from the
plugins subdirectory, and that is faster than a "make install" in the
root of ethereal.

It might also be a cleaner way to implement dissectors for proprietary protocols where you wouldn't want the dissector in the Ethereal distribution.

*If* we can get all developers whose consent matters to consent to a change to the Ethereal license to permit it to load non-GPLed plugin modules, it would also better handle non-proprietary dissectors with non-GPL-compatible licenses (actually, that was the case with the old H.323 plugin; I think it technically violated the GPL to load it in Ethereal, due to its use of an ASN.1 compiler whose output, or support library, or something such as that was under the Mozilla Public License, but nobody cared enough to complain that it was in violation).

I don't know whose consent would matter, or, if everybody in the AUTHORS file's consent matters, whether we could track them down and get them to agree. (I would have no problem with such a license change.) If it's just people whose names actually appear in copyright notices in the code, that might be easier.