The Future of the Capture/Playback Feature

tompoe has asked for the wisdom of the Perl Monks concerning the following question:

Tom Poe RenoTahoe.pm tompoe@source.net Reno, NV Seeking Perl Wisdom: And what better place to do so. I have to begin the search for solutions for the design and implementation of the Capture/Playback feature for use in mission-critical applications. As I understand the feature, it operates at the I/O level, capturing keystrokes, timestamping the keystrokes, and playing back the keystrokes in visual mode as these are saved in a "session" file. So, if I were to have the feature tied to the "Add your question" application, all these keystrokes I'm making, would be captured, timestamped, and when I started the application at some later time, and indicated I wanted to replay this "session", all the keystrokes would be recreated for my visual enjoyment. Does that make sense? Now, since I know nothing, and need to know where to begin the search for such a feature, specifically in perl, can anyone suggest a starting point? Does anyone want to know the grand vision? Well, if so, it's basically this: Utilize this feature as an audit trail for mission-critical applications that require user input of data. Each field is filled out, with each keystroke timestamped, and playback is visual, which will enable a handful of reviewers to quickly and efficiently monitor the "source" data. Timestamping of the keystrokes also makes it real nice for reporting changes to fields over time, and report those changes in various formats. I mean, is this the stuff perl is made for, or what? Well, I hope I didn't come barging in at the wrong place, wrong time, and that your replies are condescending, rather than scathing! Thanks, Tom

Comment on The Future of the Capture/Playback Feature

Replies are listed 'Best First'.
Re: The Future of the Capture/Playback Feature by Corion (Patriarch) on Jan 20, 2001 at 19:29 UTC
Retrofitting auditing / logging to an application not laid out for it is the same as writing the tests for a program / module after the code has been written - it's tedious if it works at all. My best tip is that you either rewrite your application such that every input widget allows a "tee filter" to log all the input to a logging facility, which will allow fine grained auditing, or that you use a hardware capture device to connect between the keyboard and the main computer unit (or a specialized device driver that does "tee" the keyboard input to a logging facility). If you have the luxury of being able to redesign your application, about the only things you need to change are your input widgets in such a way that they support logging and your data entry facilities ("dialogs", "windows") as well, as you will only want to log committed transactions (the user pressed the "OK" button instead of the "Cancel" button or the "Dismiss" button). Of course, this will make your application also much more testable, as you will invariably not only add a "logging" filter but also an "input filter" which will allow you to replay past transactions - which is what testing is all about. Those ideas were not made up by me but I stole them from http://www.extremeprogramming.org - look into the "regression test" section(s). Even though XP looks and sounds like just another buzzword (have a look at the ads in the Dr. Dobb's Journal), it has some ideas that just make sense - maybe you can adapt some of them.	[reply]
Re: The Future of the Capture/Playback Feature by stephen (Priest) on Jan 21, 2001 at 02:55 UTC
Not sure which "capture/playback" feature of Perl you're referring to. (And as far as I know, PerlMonks itself doesn't have such a feature...) Perl doesn't have a capture/playback function built-in. Perl doesn't deal with keystrokes in an event-driven fashion, normally; instead it deals with streams, UNIXwise. It's possible to get Perl to note the times of keyboard events, and use it to capture keystrokes, but getting such a program to intercept user events before they're passed to your application is up to the operating system and has nothing to do with Perl. If you're simply talking about parsing a file that records these events, and outputting them to the screen, again, sure, it's possible, but without any knowledge of what the capture/playback feature is, it's not possible to answer your question. In terms of general starting points for Perl, best place to start is by reading the fine manual. stephen	[reply]
Re: The Future of the Capture/Playback Feature by tompoe (Initiate) on Jan 21, 2001 at 12:35 UTC
Tom Poe RenoTahoe.pm tompoe@source.net Reno, NV Thanks, as I appreciate the input. Many years ago, when disk space was a primary consideration for everyone, there was a product, a 4GL DBMS, called AREV, or Advanced Revelations. One of the features of this DBMS, was its ability to be set up as the only application on the computer. When the computer was started, and the application was initiated, all keystrokes would be captured at the keystroke level. As a result, you could create a db for a purpose, design the screens for data input, and create reports. More impressive, though, each "session" could be played back, keystroke-by-keystroke, visually. It was as if each keystroke included a "print screen" process, and each "session" could be retrieved by displaying the screens, one after the other. Logging each keystroke, as Corion pointed out, should be exactly what is described above, except I wonder if there is some additional "loop" for having the keystrokes displayed, not as some comma-delimited text file, but rather as an executable application. Does that make sense? At any rate, AT&T Research is doing some interesting stuff in this area: http://www.uk.research.att.com/spirit/ Thanks, again,fellas, for your input. I now know this is "uncharted" territory, and that in itself is important to realize. Your humble, pathetic perlmonk follower. Tom	[reply]