Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] shared libraries

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

From: Ed Warnicke <hagbard@xxxxxxxxxxxxxxxxxxx>
Date: Thu, 22 Mar 2001 21:58:48 -0500 (EST)
On Thu, 22 Mar 2001, Gilbert Ramirez wrote:

> Guy Harris wrote:
> > 
> > 
> > 5) Put the existing dissector base into libethereal, which would also
> >    include "register.c".
> > 
> 
> This is the right way to approach it, at first.
> Eventually it would be nice to organize the dissectors into
> large plugins, so that the "ipx" plugin has the dissectors for
> ipx, spx, ipxrip, ipxsap, nbipx, and ncp, while the "ipv4"
> plugin has icmp, ipv4, tcp, udp, or whatever.
> 
> Moving the dissectors to an epan/dissectors directory
> would be appropriate, and would finally clean up our
> top-level directory. Who wants to do all that cvs work? :)
> 
> --gilbert
> 
Actually, I don't think that putting the dissectors into libethereal 
is the right long term solution ( which is not to say that it isn't 
the right short term solution).  In my mind libethereal provides a 
framework for doing useful work with dissectors.  Dissectors should depend 
on libethereal.  Applications should depend on libethereal ( and
libwiretap, but it's pretty self contained already) If we put the
dissectors in libethereal we seriously risk 
coming back to a place where libethereal has dependencies on dissectors,
which ( with the one dispensation for dissector_frame, which one way or 
another can't be avoided ) I don't think is a very good idea.  

I am more in favor over the long term of finding a way to compile the 
dissectors either as individual plugins ( or possibly clusters of 
plugins for related modules that make sense together ) or completely 
linked into a static ethereal binary.  

Moving towards a plugin architecture also forces us to remove compile 
time dependencies of dissectors on each other.  Which strikes me 
as a good direction in general.  

This being said, I don't think our current plugin architecture is quite 
up to handling a lot of plugins with run time dependencies on each other
as we currently don't have a mechanism for resolving those dependencies 
during plugin initialization.  

Clearly this will be a lot of work.  I'm willing to do a lot of it.  I 
just want to make sure calmer heads review the idea to make sure it's 
the right thing to do for ethereal as a project.

Ed