This question has probably been asked before, so I thought I'd at least put a Tennyson twist on it.
I started getting more serious about converting dissectors to the "new style". I submitted a bunch of patches where it was obvious that the dissectors fell into the "give me everything" category. My biggest worry is the comment made by Guy in bug 11134 (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11134#c13), that some dissectors want to "accept" a tvb (packet) as their own, but don't actually parse any bytes (so it appears that they would "return 0" with the new style). So the remaining ones I'm taking more slowly (with the attitude of unsure means leave as old style) and if anyone know of protocols that behave this way, feel free to convert them (or send me a note) The case I keep coming across that I'm not sure how to deal with is dissectors that get a few bytes in (and have already created trees/items for a few fields), and then decide they aren't going to dissect anymore because of a "bad" field value (most commonly "version" or "length"). Should we apply a consistent rule for this? Like if you're not going to dissect "versions" you don't support, check before making trees and just not bother with expert info saying "version isn't supported" while ceasing dissection. Or dissect as "latest version" (or at least "a" version), but with the expert info applied that the version is unknown. I'm not sure which scenario users would appreciate more, but I'd like to see it applied as consistently as possible. I believe my preference is for using expert info, but continuing dissection. Are such rules more critical for popular protocols like Ethernet, IP and TCP/UDP where there are possibly "shared" values for a subdissector identifier? Also, should we clean up a tree if a new-style dissector returns 0 (within the functions in epan/packet.c)? I think the expert info would be harder to clean up, but I'm also not sure of the difficult of the trees either. Opinions welcome, but I'd like to see the "new" style be the "only" style by the 2.2 release.
___________________________________________________________________________ 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-requ...@wireshark.org?subject=unsubscribe
