Hi, Craig.
The feature seems useful (and practical to implement) as you've
described it. Jordan's concern is also valid, but it can be addressed
by watching for rotation while the wheel is suspended. I'll apply
this feature as long as the caveats are clearly documented.
--
Rocco Caputo - [EMAIL PROTECTED]
On Oct 7, 2008, at 12:06, Votava, Craig M (Craig) wrote:
Hi Rocco-
Thanks for your thoughts on this. My view of the functionality of
pause
(although now that I think of it, maybe suspend would be a better
word)
is as follows:
When FollowTail is suspended, no buffering takes place. The current
location in the current file is preserved and if FollowTail is resumed
before any reset occurs, things proceed from that point. Otherwise the
output resumes from the beginning of the currently active file
(possibly
providing an indication of skipped data?).
I don't have a problem implementing this, the real question is would
enough people find this suspend functionality useful enough that it
should be made part of the FollowTail module, or is this just
something
that I find useful but not many others?
Thanks
-Craig
-----Original Message-----
From: Rocco Caputo [mailto:[EMAIL PROTECTED]
Sent: Monday, October 06, 2008 8:03 PM
To: POE Mailing List
Subject: Re: Pausing POE::Wheel::FollowTail?
Pausing anything that tails a file is problematic. What happens if
the user goes away for lunch, a weekend, or vacation, and the log file
rolls over more than once before they return?
A reliable solution would be to not pause. Rather, the wheel or
application would buffer changes until output is resumed. Buffered
data would need to be spooled to disk to avoid memory limits. And
then there's the chance of running out of disk if the user's gone for
a few weeks.
A compromise might be to provide a certain amount of scrollback, and
let the user browse around until their data scrolls away. While the
Tk text window is focused on historical information, it will track
that position as it continues to scroll. The user would be forced to
resume scrolling when their historical place reaches the end of the
scrollback buffer.
The most reliable solution would be to stop whatever generates log
output until the user is ready to resume. For example, pause could
run system("apachectl stop"), and resume could run system("apachectl
start"). That way you can be fairly certain the file won't change
while the viewer isn't looking. :)
--
Rocco Caputo - [EMAIL PROTECTED]
