I'll take a shot at this. I think I have some ideas that could work. -----Original Message----- From: Guy Harris <[email protected]> To: Developer support list for Wireshark <[email protected]> Sent: Fri, May 20, 2016 7:28 pm Subject: Re: [Wireshark-dev] Some questions about the "option block" interface in libwiretap
> 11) Self-writing/serializing block types: For the same reason I really don't > think self-writing of PCAP-NG blocks belongs in wtap_opttypes.c (as > relatively recently added in https://code.wireshark.org/review/#/c/14357/). I > think the optionblock should act more like a well-known list of generic and > filetype specific options that fit into that metadata category. Perhaps > formats could register a write function each for the block type, but I > personally don't see much benefit in this. The format might as well treat it > similarly to foreign encap types in its dump function, where the wiretap > determines how the information should be converted or written out for that > format. Yes, wtap_opttypes.c combines "generic" code and code to write pcapng blocks and option, so the code to handle pcapng is split between that file and pcapng.c. Code to *read* them is still all in pcapng.c, however. I think it might be best not to have the "generic" code know anything about the pcapng file format.
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
