Re: capture_file* in dissector code

[mmann78 () netscape net]

I don't think the GUI should have any specific dissector knowledge unless "absolutely necessary" (separating "business 
logic" from UI).  I know that's not how all the code is written now, but I think it's something to strive for, 
especially with the switch to qt (and how I've interpreted some of Gerald's comments about not just doing a "straight 
port" of some of the GTK+ GUI functionality)
 
I think "decode as" as a concept should be generic enough to not have to write specific GUI dialogs for each dissector 
that wants one, thus possibly requiring "dissector knowledge" in the form of specific packet_info members or "external" 
APIs from the dissector strictly for the GUI.  Which sort of puts it in a layer between dissection and GUI, so I 
thought that meant "epan directory".
 
Currently the Decode As feature has to ask "do I have a packet of type X to do a decode as operation on?".  One of the 
answers to that question is "check pinfo->mpls_label" for MPLS packets.  I think the MPLS dissector should use 
p_get_proto_data() instead of pinfo->mpls_label in a "decode as callback" to determine if a packet contains MPLS, 
rather than add p_get_proto_data() to the Decode As GUI.  I believe  p_get_proto_data/p_add_proto_data can be used to 
replace the mpls_label member in the packet_info structure, but I don't like the idea of the GUI calling it. 
 


-----Original Message-----
From: Evan Huus <eapache () gmail com>
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
Sent: Wed, Nov 13, 2013 10:46 am
Subject: Re: [Wireshark-dev] capture_file* in dissector code



On Nov 13, 2013, at 9:41 AM, mmann78 () netscape net wrote:




The ulterior motive is actually to reduce members in the packet_info* structure.  Some members could be converted to 
using p_get_proto_data/p_add_proto_data, but the "protocol ID" is required for that API.  While I've seen it hacked 
into a few places in the GUI, I think it's better design if only a dissector has access to that value.




Why? I think a few dissectors already share that value for determining the value of the parent protocol (since that is 
stored as a list of protocol IDs now) and I don't see any particular reason to restrict protocol IDs to just dissector 
code?




The idea is to have the dissectors themselves determine what gets presented in a "Decode As" by registering a "decode 
as structure". 




I'm missing how this is related to removing items from pinfo.


 

 



___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe