I think a lot of similar refactoring can be done in the area of "statistics taps". The GUI layer for many of them is (or should be) fairly thin, mostly separated by number and types of columns. By using epan (and ui) directory as a "middle layer", we can achieve more standard usage of "statistic tap names" across all GUIs. This will make migrating them to Qt easier, and will fill in some of the gaps left in TShark (where a few bugs have already been logged). Patches welcome!
Ideally, I would like to see more statistical interfaces that can be "GUI independent" so the GUI can be more dynamic in its support of dissector functionality. The one thing about this architecture that I wasn't sure about was the notion of dissectors effectively registering taps to themselves. I think taps are the right mechanism, I have just always thought of them as being intentionally separated from the dissectors.
On a related note, I took the "common" Conversation table functionality a step further and "merged in" the hostlist/endpoint functionality (
https://code.wireshark.org/review/3214/). Since I don't know a lot about conversations/endpoints, does it make sense to separate the two (from a dissector/epan API standpoint) or combine them? Is it just a "coincidence" that the same dissectors that have conversations, also have endpoints? Or would it be possible for a dissector to have one without the other? Why is the tap name "hosts" for everything but TCP and UDP (which use "endpoint"). Should there be more consistency with the naming (with the risk of breaking backwards compatibility)? I myself have been confused with all of the naming used within the code itself, let alone what gets presented to the user.
-----Original Message-----
From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
To: wireshark-dev <wireshark-dev@xxxxxxxxxxxxx>
Sent: Mon, Jul 28, 2014 6:19 pm
Subject: Re: [Wireshark-dev] [Wireshark-commits] master 31ecdf5: Refactor "common" Conversation table functionality.