From: Ulf Lamping | Richard Sharpe wrote: | | >On Sun, 22 Feb 2004, Ulf Lamping wrote: | > | >>Hmmm, I just checked in some major rework of the menu structure of | >>Analyze/Statistics: | >> | >>Sorted by ISO-layer then by alphabetical order.
Here I am again, nitpicking on ISO-OSI :) In some environments it is not really obvious to talk about a given OSI layer. This is particularly true in areas where clsssical telecom and the Internet are joined. I tend to define (parts of) the OSI stack with a starting reference point. To state it in a simple manner: user A's application layer is maybe user B's transport layer. For this reason, I feel unhappy about using absolute OSI reference layer mappings to protocols. | >Well, it does not look very nice at the moment. It creates one hugh long | >menu. | > | >Can we make it a submenu, and then sorted the way it currently is. | > | I was thinking of this topic too. | | Simply putting the stuff into a submenu will keep things in a very deep | menu structure, which should be avoided IMHO. | I tend to make a complete new toplevel menu item, maybe "Layers" / | "Details" or such, but I'm really not sure about that. | | So the toplevel menu could be one of: | | File Edit View Capture Analyze Layers Help | File Edit View Capture Analyze Details Help | File Edit View Capture Analyze Transport Application Help | File Edit View Capture Analyze Link Network Transport Application Help Personally I disagree with this scheme, for various reasons, the most important being the fact that OSI layers are relative to a reference, which may differ between end-users. | | >Also, I wonder if the old scheme did not make more sense? | > | > | Are you really sure? | All the people I was asking about the Statistics, they tell me it's a | very confusing menu structure, I agree. | so I started to think about a way to make it better. | If it's really better now is a different question. The fact that people react, means that they are interested in it :) | >For example, what is watch protocol for? It seems it was so you could get | >stats about that protocol during a live capture. | | Well, please don't blame me on the names that the functions already had ;-) | I made only minor changes to this things. | Of course, it would be good to have a better name here, any suggestions | welcome :-) | Suggestion: I would prefer (Statistics) instead of (Watch Protocol) | | BTW: This shows that the previous structure wasn't very good, as you | didn't saw this things before ;-) Unless it has been spotted by the "interest in changes" habit many people (like myself, I admit) have which has been woken up by the changes you made :) | >That being the case, wont this make life more difficult for people? | | For which people? For the one's already knowing the old structure, or | for the one's newly starting to use Ethereal? | | For me personally, when working with Ethereal captures, I usually have a | specific protocol in mind, | and now looking for some ways to get more information from it. Me too, but I cannot say I am a novice user. How about novice users? | The previous structure was the other way round, you had to have a | function in mind, | and then look after the protocols implemented this function. I think both approaches are valid. However an end-user might expect some functionality which is not present for the desired protocol because it was not implemented (yet). I think we should go for a mix of both approaches. Maybe we could have the taps register the protocol name of every protocol they act upon so we could use context-specific menus when we select a given packet or a given protocol field. Maybe we need to define *some* protocol hierarchy (like a (partial) OSI layered approach). Maybe we want to separate the protocol matter in some sort of "profiles" like telecom, Internet etc. Maybe we want to do a mix of all of this :) | I just only wanted to help .... ...which is greatly appreciated! Regards, Olivier _______________________________________________ Ethereal-dev mailing list [EMAIL PROTECTED] http://www.ethereal.com/mailman/listinfo/ethereal-dev
