Laurent Deniel wrote:
Ulf, please tell me how the uses described below (one ring buffer file
and
unlimited # of files) can be obtained with the current interface.
See below.
And please don't forget to update the doc if you want to keep the GUI
that way !
What doc do you think of? The only doc I know of this is the user's
guide. I've asked for advice
how to change it, but didn't get any response from the doc mailing list
till now :-(
Laurent Deniel wrote:
That's right.
I use the "one file" (i.e. only the packets of the last day or hour
for instance)
and "0" (i.e. unlimited) features of the ring buffer in many
situations and
in real world cases (e.g. to be able to save one compressed file of
captured
data per hours or days according to the LAN traffic or capture filters)
If I understand you correct, you want to have only one ring buffer file,
with unlimited number of switches to the next (the same file again, but
emptied out).
What is the use of *one* ring buffer file? It will be overwritten at the
next file switch so your complete history get's lost at some point in time.
I would understand a minimum of two files (as implemented), but *one*?
.
This means that [t]ethereal is *never* stopped (well unless crashes or
memory leaks ... ;-(
That can easily be achieved by *not* setting the file(s) stop condition.
The '0' in the GUI was only temporary since I wanted to have the core
features in place very quickly and without spending then too much time
in the GUI part ...
I'm a bit angry about that. Being translated this would mean:
"If anyone else cannot use or understand my GUI , that his own problem.
Should someone else may do the work of fixing the GUI."
This is a pattern: Implementing some new feature, and putting it
"somehow" into the GUI, so all features can be accessed in a way.
That's exactly (one of?) the reason why ethereal has a bad reputation
when it comes to usability.
Regards, ULFL
