Wireshark-dev: Re: [Wireshark-dev] wireshark-devel package - Was: [Wireshark-core] Working up t
Hi Joerg,
On 05/31/2011 12:02 AM, Joerg Mayer wrote:
[Moved this to wireshark-dev as it still does not belong onto
wireshark-core]
On Mon, May 30, 2011 at 04:18:31PM +0200, Balint Reczey wrote:
I still don't know how it works when we don't install header files,
network except have copy of wireshark .h files?
On Debian we ship .h files in the wireshark-dev (libwireshark-dev,
libwiretap-dev, libwsutil-dev in recent package versions). netexpect
build-depends on those packages.
OK, as this seems to repeat every 6-8 months right now, let me repeat my
standard answer to this as well: The library was never meant to be used
outside Wireshark (well, Ethereal). It was created to prevent us from linking
the same code into ethereal and tethereal. We do not have a proper API and
looking at the hoops people are jumping through to create a "devel" package
is just plain ugly: iff some people really feel they want to create a devel
package that is not endorsed by the majority of wireshark developers then at
least do it properly: create proper include files instead of just adding more
and more includes files of the normal dissctors etc. Most likely this will
need to be redone for each major release, but that's what you get when you
effectively create a fork (although for packaging purposes only).
You almost correctly summarized what I would like to see changed.
The library was never meant to be used outside Wireshark, but other projects,
like Network Expect [1] would like to use it.
In my opinion the Open Source world is about sharing. How could we capture
packets with Wireshark if the Tcpdump project did not provide the libpcap as a
shared library?
I think now it is our turn to make our libraries usable for other OSS projects.
Eloy Paris, the developer of netexpect helped a lot in separating the libraries
to new Debian packages and I also did some work to not exporting symbols on UN*X
systems not exported on Windows. Now it is also possible to easily dump ABI
information and we could use it for setting the correct library versions while
preparing releases.
In my opinion everything is ready, and we could start versioning with little effort.
You are right that we should reorganize .h files, too. I proposed this step for
1.8.0 in my one of previous emails. Currently we (the Wireshark project) provide
the .h files in the wireshark-dev package, see debian/control.
For 1.6.0 we could start by bumping the library versions to 1.0.0 and refraining
from making big changes affecting the major library version in 1.6.x releases.
The only "stable" solution that I see is to create something like ipcshark
where the dissection is running as a service and other processes just use
this service by feeding it undissected traces plus some specification on the
dissectoin details and the output format and receive the disscted stuff back
in said format. Of course you loose a bit of performance, but that is the
only stable longtime solution i see.
Since there is no officially stable representation of the undissected traces
this wouldn't be a stable solution either.
Cheers,
Balint
PS:
[1] http://netexpect.org
Ciao Jörg -- Joerg Mayer<jmayer@xxxxxxxxx> We are stuck with technology when
what we really want is just stuff that works. Some say that should read
Microsoft instead of technology.
