[Michael Mann <mmann78@xxxxxxxxxxxx>]

Ultimate goal is cleaner, more obvious and enforceable software layers.  That should lead to better flexibility, performance and code reuse.

epan is a "dissection engine" that can parse a blob of data into a form displayable and searchable on a UI. Protocol dissection was the original intent (i.e. packets), but I believe epan is general and flexible enough to apply to other areas like events or raw file structures. I want to keep it general and flexible and also fully encapsulated.  And if it is "standalone", it opens up the possibility of new applications supplying a "blob of data" source and a UI frontend (with searchability really enhancing the UI). (i.e. Stratoshark with event data and its UI or Fileshark looking at raw file bytes and displaying that as structures in a UI). 

I'm also not a fan of creating supersets in software when clearly defined layers can prevent them because it makes maintenance harder.  The current "dissection engine" calls its blobs of data "packets" that get processed into UI displayed fields in columns/trees. Protocol dissection wants to keep the name "packets" for the UI, but event and file applications have their own names, so why not have the "entity name" in its own layer (along with the columns to display)?  Yes, there are entities in epan that are specific to protocols (i.e. RTD and SRT tables) and I'm fine leaving them where they are for now as I'm not interested in trying to create whatever the "minimum dissection engine" is.

The other thing separating epan from the dissectors can do is limit what dissectors are loaded to improve startup time and memory use.  I'm not sure of how I would solve the problem (to maximize ease and flexibility), but I like the idea of a developer being able to have more control over the dissectors loaded by Wireshark, i.e. if a user of Wireshark only works with non-Ethernet related packets can they build Wireshark without 80% of the current dissectors? (purely hypothetical and would leave determining which dissectors to include up to the developer). Up until recently they couldn't because there were direct dissector/UI dependencies and I want to be able to have a CI test that proves clean layering.  Having epan as a separate library and plugging in the "no dissectors" (library) should show we still have proper layering with the UI.  And going forward we could have a "wireshark dissector" library and a "stratoshark dissector" library and a "file(shark) dissector" library.  Would still need to work out how to "filter" the various dissectors, especially if multiple applications want to share one (so just separating into folders wouldn't work).

In the MVVM [1] world I would consider epan to contain models + some view models (like the column and tree data).  The UI layer contains the remaining view models along with the view.  The 3 pane view is a popular one, so I also want the UI structured so it should be easy to create another "dissection application".  As I've said before, I don't have any need for Fileshark, but like the idea of the creating it to better modularize and encapsulate the current UI for code reuse.

This was a bit of brain dump, hopefully it answers your question and shows the direction I would like to see it go.

[1] https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel

On Wednesday, November 12, 2025 at 10:45:26 AM EST, Roland Knall <rknall@xxxxxxxxx> wrote:

Although I applaud the approach in general, it only solves the issue from a build side. There are still a lot of things happening in the epan code that directly affect UI/UX behavior (columns, statistics, resolving of names, expert information (not translatable), ...) that will not be affected. 

As much as I think it can help us be better in implementing epan, but what is the ultimate goal? To use the same library for both Stratoshark/Wireshark at runtime? To have it integrated in other projects? I am somewhat missing that context.

On the general approach, kudos and I think worth from a purely build perspective

cheers

Roland

Am Mi., 12. Nov. 2025 um 16:13 Uhr schrieb Michael Mann via Wireshark-dev <wireshark-dev@xxxxxxxxxxxxx>:

(subject line reference explained by [1])

For years I've wanted the epan directory to be a standalone library as a "dissection engine".  When Wireshark was ported to use Qt, that was an opportunity to put a lot more "dissector engine business logic" in its proper layer (epan) away from the UI.  However, still some loose ends remained (with linking issues if certain dissectors were removed).  When Stratoshark came along it seemed even more important to try to have a cleaner separation of the engine from the UI. So, I started working on cleaning things up so that epan could be its own library.

My success can be seen with [2].  Applying that patch you can build and run Wireshark without any dissectors.  You'll get a few error message pop ups from "missing dissectors", especially if you load a pcap file and the color filters try to run, but Wireshark will display the correct number of packets, with most columns not populated. (Yes, I submitted several MRs to ensure Wireshark didn't crash without dissectors and just graciously showed error messages.)

What I want is feedback from the dev-list on where to go from here.  Do people like the idea? Should "epan.lib" be more formalized? (My CMake skills aren't great, so I'd probably ask for volunteers in helping with that formalization if there is desire)

Also because of Stratoshark (and remembering the visions of FileShark [3]), I've been trying to more formally create an "application layer" library [4] (based off of wsutil/application_flavor.[c|h]) where the "dissection engine" is more parameterized to (eventually) include things like what dissectors get registered.   This would make it possible for someone to have a version of Wireshark with significantly less dissectors than the standard distribution (or provide their library of dissectors for in house development), almost as if all built-ins themselves were a single (large) plugin.  It could also lead to an application like Fileshark where the dissection engine is used to parse files for view (and only dissectors for files are built into the application).

The one "gotcha" that I have already found is that if we do have epan.lib as the "dissection engine library", that library should include the frame, file, and data dissectors and those are the basis for dissecting any piece of data.  Seems easy enough to just move the code around to make that happen (and not have those dissectors be part of the autogenerated list in dissectors.c).

What do you think?

Michael

[1] https://www.mentalfloss.com/language/look-ma-no-hands-origin

[2] https://gitlab.com/wireshark/wireshark/-/merge_requests/22275

[3] https://lists.wireshark.org/archives/wireshark-dev/201306/msg00101.html

[4] https://gitlab.com/wireshark/wireshark/-/merge_requests/21941

_______________________________________________
Wireshark-dev mailing list -- wireshark-dev@xxxxxxxxxxxxx
To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx