Ethereal-dev: Re: [Ethereal-dev] Feature request... CROP

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Ulf Lamping <ulf.lamping@xxxxxx>
Date: Mon, 19 Jan 2004 21:46:59 +0100
Chris Wilson wrote:

Hi all,


Thought I'd get some views on this before digging around in the sourcecode.

When using Ethereal I've often wanted a "crop" feature - that would discard all the packets not matched by a particular filter, so that subsequent filtering is much quicker.
This would be a valuable feature, I've often wanted something like that myself :-)

A little button next to "Clear" and "Apply" on the GUI mainscreen would be perfect.
Yes, it would fit best to the "filter toolbar" as I've started calling it yesterday. Additionally, we might want to have a menuitem e.g. under "File", but if we have the main functionality, that's easy to add.

I realise that this saving/reloading is probably going to be neccessary since all the packets will need to be refiltered once the unmatched packets are discarded.

So... do people think this sounds sensible:

A "Crop" button next to "Clear" and "Apply" on the mainscreen.
I'm not sure about the word crop itself. I currently searching for a better one, maybe "trim". As I'm not a "native english speaker", there might be better words for this I just don't see.

The button would save the displayed packets to a temporary file,
There are two possible reactions to the button press:

a.) always saving the currently displayed packets (hardwired, without any dialog box), making things work with less clicks b.) showing up a dialog box with the range frame (just like the "Save As" dialog), let the user choose the packets to be saved, making things more flexible

I currently don't have an opinion, if a.) or b.) would be better.

load the temporary file but still leave ethereal thinking it's editing the original file (so that "Save" overwrites the original file).
IMHO it would be better to display the new file as a temporary file (not as a "faked saved file"), as thats what it is. In such cases I tend to keep the original file, when saving a trimmed file, just in case I missed something out and need other packets of this file later.


One thing left to think about: what should be done, if the current file *is* a temporary file (recently captured)? As Ethereal can only handle one file at a time, the original file would be gone, when the trimmed file is made.

Hopefully I should be able to implement this without changing too much of the file loading internals.

Let me know your thoughts...

Cheers,

Chris