Re: Some questions about the "option block" interface in libwiretap

[Michael Mann <mmann78 () netscape net>]

I'll take a shot at this.  I think I have some ideas that could work.
 
 
-----Original Message-----
From: Guy Harris <guy () alum mit edu>
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
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 <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe