Ethereal-dev: [ethereal-dev] Library plans

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

From: Gilbert Ramirez <gram@xxxxxxxxxx>
Date: Thu, 21 Sep 2000 10:56:59 -0400
Last night I started working on moving the following core Ethereal
routines into a separate library.

	o Protocol dissectors
	o dissector tables
	o Proto_Tree routines
	o conversations routines
	o display filter
	o tvbuffs
	o plugin loading
	o anything else needed for the above

For the moment I'm calling this library "epan", for "Ethereal
Protocol ANalyzer".  I wanted to somehow keep the "Ethereal" name
associated with this library, since lots of people have contributed
code to Ethereal, and keeping the name was a way of honoring their
work. "Libethereal" was a candidate, but I didn't want people to
get confused by having an application called ethereal and a library
called ethereal ("Do I need libethereal if I'm using tethereal?")

Libepan won't contain any code for capturing files. It won't read
files either:  I'm also going to attempt to make it not depend on
wiretap, so that libepan can be used by a program that just wants
to decode an array of bytes. Libepan will use the wiretap encapsulation
values from wtap.h, but won't necessarily use wiretap code. I still
have to think about that.

Libepan will depend on glib, but not on gtk+.

I'd like to modify the plugin API to use dissector tables and get rid of the
display-filter-based plugin API. Since I'm not a user of the plugins, what are
people's thoughts on that?

Wiretap will become a shared library. Libepan will be a shared library.
(Options for building static versions will remain, as some people need those).

Tethereal and Ethereal will link agasint the epan and wiretap shared libraries,
while editcap links only against the wiretap shared library.

Besides helping Ethereal, this will allow other programs to start taking
advantage of both the Ethereal dissection routines (epan) and wiretap.

--gilbert