LogViewerDoc.tioga
Christian Jacobi, September 23, 1985 1:54:47 pm PDT
Last Edited by: Christian Jacobi, August 28, 1986 12:08:30 pm PDT
LogViewer
CEDAR 6.1 — FOR INTERNAL XEROX USE ONLY
LogViewer
Christian Jacobi
© Copyright 1983, 1986 Xerox Corporation. All rights reserved.
Abstract: Package which implements a single, shared log viewer.
Created by: Christian Jacobi
Maintained by: Christian Jacobi <Jacobi.pa>
Keywords: IO, Terminal, Ascii, Log
XEROX  Xerox Corporation
   Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, California 94304

For Internal Xerox Use Only
1. Interactive usage
Sequential IO for "terminal and keyboard"; ideal for logging actions.
The module keeps a log file: LogViewer.log.
Commander Commands
LogViewer     loads the package
LogViewer  open  opens the log viewer
LogViewer  new  closes the old log file and opens a new log file
2. Client Usage
Sequential IO for "terminal and keyboard"
All processes share one log viewer.
All procedures must not be called from inside a viewers-repaint or a TIP-notify procedure.
All output procedure might be delayed while input is pending.
Look at the definition module and its comments.
LogViewer.mesa
The following convention must be followed by clients:
Input is requested only as result of an interactive user action.
3. Rationale
This module is well suited for certain kind of logging actions or giving feedback.
If independent applications feedback always as immediate answer to an interactive action, it is very reasonable to share a viewer for this feedback. That is where this module should be used most.
On the other side this package probably should not be used when independent processes or applications make output at random times; in this case, these applications should better have a feedback area of their own.
This module takes care of the existence, creation and interactive deletion of its viewers; clients will not get any errors or signals on outputs. Inputs may raise UserAbort or TimeOut, but only where mentioned in the definitions module.
The input routines are a poor man's routines; they require the user to really make the input (or abort) because the package will not do any other operations until the input is finished. For simple applications this might even be what is wanted. It is specially conveniant for applications which are extended on the fly to have an easy IO handling module; Extensions are eased if they need not deal with viewer creation of the main application.
The strict following of the input convention guarantees that the user is not forced to switch his awarness to a different application at random times.
The fact that users can always abort input guarantees that client programs can not lock other clients out of doing feedback. (The private procedure AddLock is the exception; thats why this procedure is private.)