["Olivier Biot" <ethereal@xxxxxxxxxx>]

From: Ulf Lamping

| Olivier Biot wrote:
|
| >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.
|
| I don't think that's true (at least on the protocols we currently
have
| taps for),
| e.g. the IP protocol is a network protocol, regardless what's above
and
| what's below it and what you are doing with it in your specific
task.

Umm... maybe I am 100% wrong but if I remember correctly from some
discussions with 3G (aka UMTS) people, the IP layer is the
*application* layer when we're dealing with say the IMS, while for me,
looking at the IP on top of this IMS low-level stuff, IP is indeed the
*network* protocol. Of course, I agree that if you *only* look at IP,
then the IP protocol's use is as a network protocol.

| It might be true that you have multiple network protocols
| in your stack, but that doesn't change the facts.

I get your point. You would propose to add *all* network protocols in
the *OSI network layer* menu item, and do the same for all OSI layers.
That sounds feasible today as we only have a limited set of protocols
for which we generate statistics.

Doing so would already offer some more logic in the menu than what is
available today, however it does not allow a user to see the OSI stack
in which a given protocol fits. We then still need to deal with
situations where stats are being generated for more than one protocol
at the same time.

And that's a question I have right now: do we want to sort the items
in an OSI stack manner, or do we want to do it in a per-OSI-stack
family (telecom signalling, IP, etc)? We can probably only answer this
question by trying out one way, and then evaluate the situation with
end-user feedback.

| There might be other protocols, where it's not that sure.


| And keep in mind: *if* you are doing this and trying to analyze
things,
| you will usually *know* that you're doing
| "unusual things" with it, and what the usual "use case" would be (so
| where you have to look at).

Here I lost the track, sorry.

| >| 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 :)
| >
| Sorry, but I'm pretty sure you are really doing overkill on this
topic
| right now!!!

Honestly, I don't see a problem in listing options as a hint for the
future, while you are working *now* on a fix which can be implemented
in a fair amount of time. Sometimes this approach helps in finding a
(sometimes obvious) solution.

| Context specific menus! Do you really have the time to implement
this?

I guess not. Besides, I still need to read much GTK code before I
attempt at doing one of the maybe esoteric changes I proposed, and
which were mainly meant as input for a discussion for some long-term
solution.

| I wanted to find a solution which could be implemented in a
reasonable
| amount of time.

This is 100% clear to me and makes sense to the same extent :)

However, what I wanted to *suggest*, is (a) that we may want to sort
the menu items in application categories, such as "IP", "telephony",
"VoIP", "ATM", "Frame Relay" etc in order to define the menu trees in
a more intuitive manner. This has also been suggested by Michael
Tuexen. Of course, intuition sometimes is something of a personal
matter :) Additionally, (b) we might want to look at one or more
long-term solutions which (I agree) might or might not be relevant
anymore after we've seen the short-term solution.

| There are many other things in the GUI that are in definite need for
| some rework too ...

Agreed. But let's discuss only the menu stuff for the stats for now. I
am happy to see Ethereal evolving like it is today!

Regards,

Olivier