Re: Hierarchy of fields & offsets again, more potential offenders

["Sultan, Hassan via Wireshark-dev" <wireshark-dev () wireshark org>]

> -----Original Message-----
> From: Wireshark-dev [mailto:wireshark-dev-bounces () wireshark org] On Behalf
> Of Pascal Quantin
> Sent: Thursday, August 10, 2017 2:19 AM
> To: Developer support list for Wireshark <wireshark-dev () wireshark org>
> Cc: Sake Blok <sake () euronet nl>
> Subject: Re: [Wireshark-dev] Hierarchy of fields & offsets again, more potential
> offenders
>
>
>
> Le 10 août 2017 10:56, "Stig Bjørlykke" <stig () bjorlykke org
> <mailto:stig () bjorlykke org> > a écrit :
>
>
>       On Wed, Aug 9, 2017 at 7:05 PM, Pascal Quantin
> <pascal.quantin () gmail com <mailto:pascal.quantin () gmail com> > wrote:
>
>       > What about marking it as PROTO_ITEM_SET_GENERATED() as a first
> step? Tis
>       > value is inferred from the tvb length and not a real field.
>
>
>       It's not a generated field (the bytes are fetched directly from the
>       packet without any modifications) so this would be wrong.
>
>
>
> Right I missed the fact that we are also highlighting the payload in the bytes
> panel and not only indicating the length. So I agree it is not suitable.
>
>
>
>       I suppose Sake has a use case for the tcp.payload which may lead us to
>       a hint for how to mark such fields?
>       Because we may end up with udp.payload, ssl.payload, http.payload,
>       sctp.payload, tftp.payload, etc. and that would mess up a bit if we
>       don't handle them correct.  Right?

Me and Pascal have been having a discussion on https://code.wireshark.org/review/#/c/22937 on how to represent sets of 
fields that are related but non-contiguous.

As part of a discussion, one idea I had (and which Pascal feels won't be adopted by dissector developers) was to use 
ft_value to add 'linkage' between fields.
Basically add to the union inside ft_value a proto_item entry, and we could add various types specifying the type of 
link between fields : 
- one field is an alternate view of another
- one field is semantically linked to another (to handle the non-contiguous fields that the UI may want to display 
together)
etc...

To me this is something that can be added in steps to the current dissectors. Wireshark would still represent fields as 
it does today, and add the new way when it detects fields with the new ft_value entries. And over time as we find 
fields that need to be modified we transition them, up until they're all transitioned. Users should hopefully see no 
difference when using the UI, and we get better semantic description of the protocol for automation.

Thoughts on that approach ?

Hassan

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