Re: capture_file* in dissector code

[Evan Huus <eapache () gmail com>]

On Wed, Nov 13, 2013 at 11:25 AM,  <mmann78 () netscape net> wrote:
> 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)

Agreed, but things like the TCP stream graph inherently require
specific dissector knowledge, so we'll never get rid of it entirely.

> 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.

I wasn't aware that Decode As was this complicated at all - I thought
it simply referenced the various dissector table registrations to
generate the relevant lists? Should it not simply be checking if there
are registered child dissectors?

> -----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
___________________________________________________________________________
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