On Nov 12, 2025, at 10:20 PM, Michael Mann via Wireshark-dev <wireshark-dev@xxxxxxxxxxxxx> wrote:
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.
...both of which it already does dissect. 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).
So would there be a separate epan library (currently "libwireshark", but, if it's just a dissector *framework* with no dissectors, perhaps it should be renamed) and dissector libraries (one for Wireshark and TShark, one for Sttratoshark and Strato, and potentially one for Fileshark and TShark)?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)?
And Wireshark/TShark, at least, has entities other than packets that it dissects, so that the entity name would be based on the type of record.And going forward we could have a "wireshark dissector" library and a "stratoshark dissector" library and a "file(shark) dissector" library.
Exactly. |