Ethereal-dev: Re: [Ethereal-dev] Capture ringbuffer behaviour, 2nd proposal
Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.
From: "Lars Ruoff" <lars.ruoff@xxxxxxxxxxxxxxxxxx>
Date: Mon, 1 Mar 2004 18:06:40 +0100
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
- References:
- RE: [Ethereal-dev] Capture ringbuffer behaviour, 2nd proposal
- From: Biot Olivier
- RE: [Ethereal-dev] Capture ringbuffer behaviour, 2nd proposal
- Prev by Date: Re: [Ethereal-dev] SPARC Optimizations With GCC - OSNews.com
- Next by Date: Re: [Ethereal-dev] Directory settings
- Previous by thread: RE: [Ethereal-dev] Capture ringbuffer behaviour, 2nd proposal
- Next by thread: Re: [Ethereal-dev] Capture ringbuffer behaviour, 2nd proposal
- Index(es):
- Get Wireshark
- Download
- Code of Conduct