Not if we can get then into 2.2 in time. It seems like the bugs that were created by the first refactoring have been fixed, so maybe its time to think about the next layer. When I was last working on it my big concern was option "datatypes". The existing blocks that were refactored didn't have too much variety and were mostly strings and integers which was easy enough to handle. It seems like a generic solution would involve something like what we have with ftypes (registering datatypes with their handlers) and that seemed like a lot of work. Maybe now is the time to discuss alternate ideas?
-----Original Message----- From: Guy Harris <[email protected]> To: Developer support list for Wireshark <[email protected]> Sent: Mon, May 16, 2016 2:06 pm Subject: Re: [Wireshark-dev] Some questions about the "option block" interface in libwiretap So we'll probably be making incompatible API changes to the libwiretap code in future releases, such as 2.4.0, to handle some of these issues. ___________________________________________________________________________ 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
___________________________________________________________________________ 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
