Hi,
see my comments below.
Best regards
Michael
On Feb 19, 2004, at 10:31 AM, Biot Olivier wrote:
|From: Michael Tuexen
|
|Hi,
|
|I do understand the difference, I was more talking about
|the way the user can handle this feature.
That's another story, with which I agree that we must make the feature
as
intuitive as possible to an end-user.
|If I want to delete some packets I just mark them,
|choose 'hide marked packets' an the remaining packets
|are re-dissected.
That's not true: *all* packets are being redissected, but the marked
packets
will not show up. That's different from really *ignoring* the packets
flagged as deleted, so they don't influence dissection anymore.
Consider the
following packet capture:
What I mean is that when you choose 'hide marked packets' only the
shown packets are re-dissected. I think we agree on the stuff
begin done internally, I'm only trying to find a way that the
user has not two ways of doing the same thing: Selecting packets
for being marked and selecting packets for being deleted.
Maybe my wording should be better:
One option should be:
'delete marked packets'
the other
'delete unmarked packets'
I just wanted to avoid the term delete because they are not deleted
they are 'just' not used for dissection and therefore not shown.
That is the reason why I used hide/show instead of the term delete.
1. WSP Connect
2. WSP Redirect to some nonstandard server socket
3. WTP Ack
4. WSP Disconnect
5. WSP Connect to the redirect address from packet 2
6. WSP ConnectReply
7. WTP Ack
If I flag packet 2 as deleted, then a *new* redissection would not
yield
WSP-over-WTP dissection for packets 5--7 if the redirect address does
not
contain a standard WSP-over-WTP port. If I only flag the packet as
marked,
then it will still influence the dissection.
Maybe we should not talk about "deleting" a packet, but rather:
a. Remove packet [from dissection]
b. Skip packet [dissection]
c. Ignore packet [dissection]
I like ignore.
So you could have a menu item for
'ignore marked packets'
and
'ignore unmarked packets'
Regards,
Olivier
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev