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
