Re: Do we really need port preferences for dissectors?

[Guy Harris <guy () alum mit edu>]

On Feb 5, 2016, at 1:59 PM, Michael Mann <mmann78 () netscape net> wrote:

> One of the reasons I try to stay away from UI design/development is that I'm never sure if new ideas for existing 
> behavior are "good", "bad" or they are "good" but existing users react with "who moved my cheese?"

I'm not averse to moving stuff - e.g., making "Save As" work the way "Save As" is supposed to work and works in other 
applications, and moving the "save some but not all" packets to another function - but the current UI moves items to 
control the choice of protocols not controlled by a protocol field to a very non-obvious place, corresponding to moving 
the cheese into a hidden drawer under the sink behind the trash can.  When confronted by the current "Decode As" 
dialog, my first question is "OK, what am I supposed to do now"?

So I think that dialog is definitely bad.

In the case of MPLS, for example, the way you *used* to say "dissect everything for which there's no explicit label -> 
protocol binding as XXX" is to go to the MPLS preferences and set the "Default dissector for MPLS payload" preference 
to the appropriate value.

Now, you, err, umm, what?  I open up the trace file from

        https://www.cloudshark.org/captures/b3ad42cb58cd

which was the MPLS-related question, and select one of the packets in question, and pop up "Decode As" - what next? I 
guess I select "MPLS protocol" from the top list in the combo box (what's the significance of the two lists?), and 
choose the dissection for that - but that only fixes it for packets with that particular label.  I then have to hit all 
the *other* labels in the capture the same way; the ability to specify a *default* seems to have disappeared in this 
change.

I don't consider that disappearance an improvement.

At this point, I think we need to stop and rethink "Decode As" before we do anything further.

For starters, we should allow a "Decode As" item to offer a "default" option, so that a user can say "decode as XXX all 
MPLS labels for which we haven't set up a specific "decode this as"", so that we can restore the capability that the 
"Default dissector for MPLS payload" used to offer.  "Default" items in the "Decode As" list should probably *always* 
be displayed, regardless of whether the user has set them or not, so that the user doesn't have to do anything to see 
them.

In addition, we should have a way to say "decode this conversation as", for all conversation types, so that you could, 
for example, just click on a TCP packet and say "decode this conversation as HTTP" without adding a possibly-persistent 
Decode As entry.

> Some dissectors having a preference for their TCP/UDP port and forcing others to use Decode As is the inconsistent UI 
> behavior that I would like to change.

Yes, and, once we've done that, perhaps the "Value" column should, for uint dissector tables, be a range field.  Then a 
dissector entry that's replaced by a preference should *always* appear in the "Decode As" list, regardless of whether 
the user has set them or not, so the user doesn't have to do anything to see it, even if the list is empty.
___________________________________________________________________________
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-request () wireshark org?subject=unsubscribe