Re: capture_file* in dissector code

[Evan Huus <eapache () gmail com>]

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

>  Something of a cross between the dissector_filter(.c) functionality an a UAT.  I also thought it could help qt 
> development by providing the data "outside the GUI", reducing the effort there.  I'd like the decode_as_ok() (in 
> decode_as_dlg.c) to just loop through an array to determine if there is something to "decode as".   As I've looked 
> into it further, the problem is that decode_as_ok() uses dissectors and taps.  I was originally just focusing on the 
> dissectors, but knew I needed the "decode as structure" to support a capture_file* in some capacity for the taps (and 
> I've prefer to avoid an architecture that uses void* but the underlying functionality knows exactly what type of 
> pointer it is), hence the post to -dev.
>  
> -----Original Message-----
> From: Evan Huus <eapache () gmail com>
> To: Developer support list for Wireshark <wireshark-dev () wireshark org>
> Sent: Wed, Nov 13, 2013 9:21 am
> Subject: Re: [Wireshark-dev] capture_file* in dissector code
>
> What does "more generic" mean in this context?
>
> On Nov 13, 2013, at 8:15 AM, mmann78 () netscape net wrote:
>
> > I was looking at making the "Decode As" functionality more generic, but my current solution involves having 
> > dissectors handle a callback function that passes in a capture_file* as an argument.  Is that valid or does it cross 
> > library boundaries creating unwanted dependencies?
> > ___________________________________________________________________________
> > 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
> ___________________________________________________________________________
> 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