["Ulf Lamping" <ulf.lamping@xxxxxx>]

Biot Olivier <Olivier.Biot@xxxxxxxxxxx> schrieb am 21.10.03 18:14:09:
> 
> 
> Excellent overview!

:-)))
> 
> Regarding "Edit->Mark Frame" feature, I'd like to have an
> "Invert Selection" as a minimum addition.

I only wanted to rearrange existing functionality, not extending or adding new things, sorry
> 
> "View->Show frame in new window": replace with
> "View->Frame in new window"

Ok, changed in the doc
> 
> I suppose the "Analyse->Decode As" will still be available
> by right-clicking on a packet in the tree pane? 

I'm currently unsure about this point.
> If so, we
> can then also get rid of "Analysis->Follow TCP Stream".

Answered by Guy already
> 
> Should "TCP Stream Analysis" be part of "Analyze" or of
> "Statistics"? IMHO both menu items overlap in functionality.

As I don't use this items very much, there might be a better arrangement between Analyse and Statistics items. Need some good advice on this topic.
> 
> 
> Regarding the Packet versus Frame discussion, I think this is difficult to
> circumvent as every protocol defines an own name for its SDU/PDU. Ethernet
> and Frame Relay talk of frames, while ATM talks of packets :) Upper-level
> protocols define their own jargon: TCP segments, IP datagrams, others define
> PDUs that convey SDUs etc... So all depends on the lowest-level protocol in
> the capture.
> 

Well, I don't meant to change names in the dissector fields, as there are good reasons to use the common names for the specific protocol, as you have outlined.

What I meant, was all the generic GUI elements (most of them have nothing to do with specific protocols), like the menu, Print Dialog, Summary Dialog and wherewever else. IMHO it isn't a good idea to call it sometimes Frame and sometimes Packet at that elements.

> 
> Regarding capture versus display filters, I thought Ethereal once intended
> to be rather independent from the packet capture interface, and for this I
> think it is OK to keep both (capture and display filter language)in. However
> I agree that not all users have access to pcap man pages, so we will have to
> provide at least an URL and ideally a pcap man page to Ethereal.
> 
> Maybe we can provide a "Cool tip of the day" feature where FAQ items (and
> the capture versus display filter language) are displayed as pop-up on start
> of Ethereal (and via an "i" button on Ulf's new toolbar?)...
> 
The thing is: users have to *remember* the two languages, which makes it difficult for a new or unregular user. Believe me, this is the *main* point criticised by *all* the people I speak at my department, who uses Ethereal.
> 
> Something not mentioned here but discussed over the last few days, is
> providing a mechanism that prevents automatic rescan of the entire packet
> list when the end-user is not yet done with configuring (e.g., IO-stat
> automatically scans the packet list at almost every click). Instead a button
> "Apply" should be foreseen.
> 
I only wanted to rearrange existing functionality, not extending or adding new things, sorry


Regards, ULFL
______________________________________________________________________________
Zwei Mal Platz 1 mit dem jeweils besten Testergebnis! WEB.DE FreeMail
und WEB.DE Club bei Stiftung Warentest! http://f.web.de/?mc=021183