Re: Do we really need port preferences for dissectors?

[Michael Mann <mmann78 () netscape net>]

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?"
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.  To me that is different than "different paths" in the UI (For example having 
Decode As dialog (for TCP-> XXX) as currently constructed and all TCP dissectors having a section in their preferences 
for "reverse Decode As" (apply this to TCP port).

I just wanted to mention the "big picture" as something to move towards.  Adding "other parts" to the UI (as long as 
they are consistent for ALL dissectors) is fine with me.

 
 
-----Original Message-----
From: Guy Harris <guy () alum mit edu>
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
Sent: Fri, Feb 5, 2016 4:18 pm
Subject: Re: [Wireshark-dev] Do we really need port preferences for dissectors?

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

> I'm not surprised we're getting those questions, but for me I'd like to work towards the goal of providing an overall 
> solution for heuristics and get away from dissector specific ones.

There's "dissector-specific" in the code and there's "protocol-specific" in the UI.  The two are not rigidly tied 
together.

I *really* don't want to have users who just want to tweak the way Ethernet MPLS pseudo-wire dissectors have to pop up 
"Enabled Protocols" , search for "PW" or "Ethernet" in that huge list, and enable or disable the appropriate protocol - 
or possibly pop up Decode As and have to *create a new entry* - rather than popping up a dialog that presents an 
*existing* list that *includes* MPLS, and lets them select the MPLS item and edit it.

I.e., I think 2.x's UI for changing those settings is inferior to 1.x's, even if the underlying *dissector code* is 
cleaner.  I think the set of questions we're getting is a sign that, at the UI level, we've made a mistake and reduced 
the usability of Wireshark.

> Right now the functionality I'm talking about fits into our existing Decode As, so that's why I'm suggesting putting 
> it there.

I think we should rethink how the Decode As UI works *now* before adding anything to it.

For example, we should have at least one dialog that includes entries for every protocol for which you *can* adjust 
settings, *regardless* of whether the user has changed any settings from the default.

> Long term (probably post 2.2 release) I'd like to see Decode As, enable/disable protocols, enable/disable heuristic 
> dissectors, "conversation Decode As" (and maybe other items I'm forgetting) all somehow merged into a single UI data 
> representation.

Single *internal* data representation, fine.

Single *place in the UI*, not necessarily.  From the UI standpoint, what matters is how obvious is it to the user where 
to do something, *not* how clean the data structures are - we may well have different parts in the UI for different 
types of things in the data structure.
___________________________________________________________________________
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

___________________________________________________________________________
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