Ok.
But is there really a need for having a file number limit when not using
ring buffer??
I mean, it is highly redundant since users can easily calculate the number
of files given their capture limits and the file size.
and then we could just replace
[c] Maximum number of capture files: [2]<rotating list>
[d] Overwrite oldest capture files when maximum
number of capture files has been reached.
by
[c'] Back to first file after: [2]<rotating list> files. (Use ring
buffer)
(as in Ulfs initial proposal)
This saves us another (possibly confusing) checkbox line and ensures that
never ever will someone get the surprise that its capture has been stopped
automatically
allthough he didnt set any limits in the "capture limits" section.
Lars.
----- Original Message -----
From: "Biot Olivier" To: "'Ethereal development'"
<ethereal-dev@xxxxxxxxxxxx>
Sent: Monday, March 01, 2004 5:16 PM
Subject: RE: [Ethereal-dev] Capture ringbuffer behaviour, 2nd proposal
> |From: Lars Ruoff
> |
> |From: "Jason House"
> |> Both approaches (I believe) would separate
> |> "Capture Files" from "Capture Limits"...
> |> I think Biot's comments was just the
> |> "Capture Files" section.
>
> Correct.
>
> |The point is that if you use a maximum file number
> |but do *not* use the ring buffer, then it
> |effectively limits your overall capture -
>
> Correct: for example limit to 5 files and set next capture file every 300
> seconds. This yields a capture to 5 files, which will stop after 30
minutes.
>
> |so my logic was that it should go into capture
> |limits!
>
> I partly agree. The funcitonality is similar but different :) In the
example
> you state and I gave, you effectively move to a next file when the "file
> rotation condition" is met.
>
> Do we consider "file rotation condition" and "capture stop condition" as
> mutually exclusive or as complementary? Today it's the latter, and it's OK
> to remain so.
>
> I however agree that the widget is probably the most cumbersome of
Ethereal
> today :) but it is not that easy to find a better solution. For this
reason,
> I posted a proposal where you must enable multiple-file capturing with a
> check box. I see a total implementation as follows:
>
> File: [_____________] [Browse button]
>
> [a] Write to multiple capture files
> (b1) Next capture file every [___[100]]<rotating list> packet(s)
> (b2) Next capture file every [___[100]]<rotating list> kilobyte(s)
> (b3) Next capture file every [___[300]]<rotating list> second(s)
>
> [c] Maximum number of capture files: [2]<rotating list>
> [d] Overwrite oldest capture files when maximum
> number of capture files has been reached.
>
> [e] Specify a total capture limit
> (f1) Stop after [___[100]]<rotating list> packet(s)
> (f2) Stop after [___[100]]<rotating list> kilobyte(s)
> (f3) Stop after [___[300]]<rotating list> second(s)
>
> I think this UI layout is a compromise between intuitiveness and
complexity.
> If check box [a] is not checked, then all controls (b), [c] and [d] must
be
> grayed out (deactivated). The same applies to (f) when [e] is not checked.
> Doing so allows the end-user to see what happens. If they want a global
> capture limit, they need to enable it and choose a limit type. The same
> applies if they want to use more than one capture file.
>
> Regards,
>
> Olivier
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
