Hi,
I do understand the difference, I was more talking about
the way the user can handle this feature.
If I want to delete some packets I just mark them,
choose 'hide marked packets' an the remaining packets
are re-dissected.
Best regards
Michael
On 18. Feb 2004, at 19:21 Uhr, Olivier Biot wrote:
Hi list,
First I'll try to explain why I looked at the packet deletion thing. I
was looking at the Wish List and I found the following entry:
22. The ability to delete packets in the packet list.
Of course we still need to define what we understand with deleting
packets :) which is one of the reasons of this RFC.
There's the possibility to Mark packets today. This does *not* affect
packet dissection at all. I think Gerald meant to functionally remove
a packet from a capture file, hence skipping it in subsequent
(re)dissections. This implies that the outcome of dissection *may*
differ from the initial dissection, as is the case with the "Decode
As" feature.
----- Original Message -----
From: Michael Tuexen
| What about a feature which allows us to
| hide all marked packets
| or show only marked packets?
I have been thinking at that, but then I realized that some packets
influence the dissection. Marking a packet doesn't influence the
dissection.
| On 18. Feb 2004, at 18:56 Uhr, Richard Sharpe wrote:
|
| > On Wed, 18 Feb 2004, Ulf Lamping wrote:
| >
| >> Olivier Biot wrote:
| >>
| >>> Hi list,
| >>>
| >>> I'd like to implement packet deletion. for many things deeting
| >>> packets
| >>> is *very* similar to marking and unmarking packets. I however
have
| >>> some questions, so I list some statements below:
| >>>
| >>> 1. If I delete a marked packet, I should unmark it too.
| >>> 2. All (context) menu items on a deleted packet must be
disabled,
| >>> except for undeletion.
| >>> 3. If a deleted packet is selected, its dissection tree must not
be
| >>> shown.
| >>> 4. Deleting packets in a capture may change the way a capture is
| >>> dissected. For example, if I delete a WSP redirect packet, then
the
| >>> redirection conversation will not be built if the packets are
| >>> processed again.
| >>> 5. Because of 4. we may want to have a "redissect" button be
active
| >>> whenever we suspect something will change dissection.
| >>> 6. Deleted packets "never" match a display filter.
| >>>
| >>> Comments are welcome!
| >>>
| >>>
| >>>
| >> What do you mean with packet deletion?
See above: functionally skip a deleted packet from the packet list. In
other words: dissect the captuer file as if the deleted packets were
not present.
| > I think he means to mark them as deleted.
That's the way I want to implement it by adding a 'deleted' flag to
the flags struct, similar to the 'visited' and 'marked' flags. I
already have written some proof-of-concept code which I will send
after the 0.10.1 release.
| >> Do you want to simply hide the packets, or really remove them
from the
| >> capture file?
| >
| > I don't think it will be easy to delete them from the capture
file. We
| > will have to write the capture file out again to do this.
Physically deleting packets from the capture file can always be done
with the "Save As" function, indeed. In-place deletion of packets is
another story.
Regards,
Olivier
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
