On Nov 12, 2025, at 10:20 PM, Michael Mann via Wireshark-dev
<[email protected]> 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.
_______________________________________________
Wireshark-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
