 |
Description  |
|
|
BACKGROUND OF THE INVENTION
This invention relates to providing echo in the form of user-discernible
system response to user-initiated actions which require such response
within bounded response times. More particularly, the invention is in the
field of multi-user systems wherein user access to an application program
in a host computer is obtained through workstations remote from the host
computer, and responses to certain user actions in the context of an
application program are provided by a protocol which is proximate to the
user instead of by the remote application program.
The mechanization of modern offices has led to multi-user systems in which
a plurality of user workstations are connected to a single host computer
that provides application program processing services to one or more of
the workstations. Typically, the workstations are geographically
distributed throughout an organization and communicate through a
centralized communication facility with the host. In order to provide
specific application program services to the workstations, the host is
typically time-shared among the workstations.
Modern application programs are characteristically event-driven processes
in which interaction occurs between the program and the user. In these
cases, interaction is most frequently afforded through a workstation
terminal that includes a variety of user input devices and a graphical
output device such as a CRT. The user inputs commands and parameters to
the application program through the input devices and observes the program
responses on the screen of the CRT. When described as event-driven, it is
understood that the application process waits for a specific
user-initiated action before it undertakes a computation based on user
input and provides a response to the user via the CRT.
User actions or events may cause computational response from an application
program. Such events follow, for example, entry of a command or depression
of an ENTER or RETURN key on a workstation keyboard. It is to be
understood that other user-initiated actions do not require computational
response from an application program. Such actions include entry of
characters typed on a keyboard that form a command, implement cursor
movement, or signify sectors of a display tableau by highlighting. Most
user actions generally do require immediate notification to the user of
registration of the current parameter provided by the input device
operated by the user.
In order to apprise the user when an action is registered in an interactive
system, feedback is provided in the form of user-discernible responses to
the actions. Such responses are termed "echoes." The response to a user
action requiring computation is provided by the application program as an
indication of the outcome of the requested computation. For example, in a
spreadsheet program, the application program may provide the outcome of a
calculation based on a formula and parameters provided by the user.
The echo response of a system to user-initiated actions is normally
provided by an output device at the workstation. Thus, characters entered
on a keyboard are echoed to the user by being displayed on the CRT screen,
and operation of cursor control through a keyboard or a mouse is echoed by
moving the position of a displayed cursor. Other echo responses include
highlighting selected commands, movable objects, or "cells" of a CRT
display into which a cursor has been moved.
In most prior art systems, the echo response to user action is typically
the responsibility of the application program, which acts through a
graphic display service to generate a graphics display on a CRT. A typical
graphic service is described in Foley and Van Dam, "Fundamentals Of
Interactive Computer Graphics," Addison-Wesley, 1982, at pp. 35-90. In
most cases, the application program generates low-level descriptions of
the composition and location of objects and text to be displayed and
passes them to the display service. The display service translates the
descriptions into control signals which cause the CRT to display the
objects and text at the indicated locations. Updating or changing an
object or location as an echo of a user-initiated action thus normally
follows a pathway to the application program and back to the display
service.
In the remote workstation environment, where the application program is at
a distance from the user input devices, display service, and CRT, the
roundtrip between the workstation and the host computer where the
application program is located can consume a considerable amount of time.
Further, in the case where a plurality of workstations access a single
host computer, the roundtrip time for the same echo response at the same
workstation can vary as a result of contention for host resources.
Lengthy and variable delay between a user-initiated action and an
application program response can be tolerated in the case of
computation-initiating actions as a necessary concomitant of multi-user
system organization. However, in the case of user actions that require no
computation, such as text editing, cursor movement, and highlighting, for
example, long or variable delay in system response can seriously detract
from the efficiency of program utilization. Indeed, the echo response
should be immediate or instantaneous. Therefore, a need exists in
multi-user systems in which remote workstations access a host computer for
application program services to reduce the time used by the system in
responding to user-initiated actions that require immediate feedback to
the user.
In other graphics processing systems, echoing can be the responsibility of
terminal hardware and/or operating system software at the terminal. In the
former regard, hardware echoing requires terminal hardware dedicated to a
specific application; if another application is desired, another set of
terminal hardware must be used.
Operating system echoing is represented by a minicomputer operating system
such as UNIX (UNIX is a trademark of Bell Laboratories). In these systems,
echoing is typically implemented at a very low level of abstraction in
much the same manner as an output device driver. As in the case of
hardware echoing, operating system echoing incorporates a set of
output-device-specific response functions. This results in a system which,
from the standpoint of the application user, is inflexible and extremely
difficult to adapt to the needs and proclivities of the user. Such systems
are not intended to be alterable at the point where a graphics application
program interfaces with the system's graphics processor.
An object of the invention is therefore to reduce the time required for an
echo response to be made to user-initiated actions in a distributed
multi-user system having a central computer which provides application
process services to the distributed users.
SUMMARY OF THE INVENTION
The solution to the problem described in the background section is founded
on the observation that echoing or reaction processes can be extracted
from a remote application process and located in proximity to the event
registration and display support facilities of the system. In this regard,
an application protocol is located at a workstation to be proximate to the
application program input and display support services. The application
protocol receives all user-initiated actions and separates
computation-initiating actions requiring application program computation
or processing from actions requiring only an echo response. The first type
of user actions are forwarded through the system to the application
program located in the host computer. The second type of user actions are
evaluated by the application protocol to determine the proper echo
response and are passed to the display support facilities for echo
resolution. It is recognized that some user actions may require both a
computational and an echo response from the system. In responding to these
actions, the application protocol separates and forwards the portion of
the action requiring computational response. The echo portion of the
response is activated locally by the protocol.
Further, the extracted echoing processes are functionally located in the
workstation at the interface between the application process and the local
graphics resources. Consequently, the application protocol can be
expressed in system terms at a relatively high level of abstraction not
dependent upon specific characteristics of the output device providing the
echo. This permits the protocol to be easily expressed and constructed,
for example, by being remotely programmed at a workstation by the
application program. The invention therefore imparts graphics flexibility
and adaptability to the application processing context, which are not
provided by hardware and operating system echoing.
The invention is expressed as a method for controlling the echo of an
application process to user-initiated actions at a man-machine interface
in a distributed computational system that has indeterminate length
message passing delays. The echo controlled is the reaction to
user-initiated actions requiring a direct, user-discernible notification
from the system within bounded response times but not requiring
computation by the application process. In the method, processes requiring
user-discernible echoes within bounded response times but not requiring
computation by an application process are extracted from their counterpart
application processes. The extracted processes are located in proximity to
input and display support facilities of the system and linked directly to
these facilities and to the application process. Input parameters
descriptive of user actions are passed from the input facilities to the
extracted processes within a first interval. The echo response required to
the input parameters is ascertained by the extracted processes within a
second interval. Parameters from the extracted processes are passed to the
display support facilities for echo resolution within a third interval.
Finally, other parameters are passed from the extracted processes to the
remaining application processes.
Alternatively, the invention is a system for controlling the echo response
of an application process to user-initiated actions at a man-machine
interface in a distributed computational system in which the application
process is separated from the interface by a message pathway that imposes
indeterminate length message passing delays between the application
process and the interface. The system includes a display for providing
visual outputs from an application program to a user and a display service
responsive to application program output parameters for operating the
display. One or more input devices provide application program input
parameters in response to user actions, and a message exchange service
transfers application program parameters between the local system and the
computational system. An application protocol process proximate to the
display service, the input devices and connected to the input devices,
display service and the program exchange service extracts, from input
parameters provided by the input devices, input parameters indicative of
user action requiring user-discernible response within bounded response
times, transfers the extracted input parameters into echo response
parameters, and passes the echo response parameters to the display
service. The transformation of extracted input parameters into echo
response parameters requires computation by an application program.
The above stated objectives and other advantages of the invention will
become more apparent when the following detailed description is read in
light of the drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of a distributed computational system;
FIG. 2 is a block diagram illustrating in greater detail the major blocks
of a workstation in the distributed computational system of FIG. 1;
FIG. 3 is a block diagram illustrating distribution of application program
processes according to the method of the invention;
FIG. 4 is a flow diagram illustrating an embodiment of the invention as an
application protocol procedure; and
FIG. 5 is an illustration of data structures utilized by the application
protocol of FIG. 4.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
In FIG. 1 a distributed computational system includes a host processor 10
which is connected to provide services to a plurality of remotely-located
user workstations, two of which are indicated by 14 and 16. The host
computer 10 is conventionally configured with a host operating system (OS)
that controls execution of application programs stored in the computer. As
is known, the operating system may include a control program (CP) that
cooperates with the OS to control access to and use of host resources in
the execution of application programs stored in the host computer 10.
Representative of the OS and CP, respectively, are a UNIX-based operating
system, and the Virtual Resource Manager, both available from IBM.
Together, these structures are used in a commercially-available IBM
multi-user workstation system denoted as the IBM RT/PC.
Preferably, access to the host computer by one of the workstations is
provided through a communication service 24 which has transmission paths
26 and 28 to the stations 14 and 16 and a single transmission path 30 to
the host computer 10. The communication service 24 can comprise a
conventional facility for interconnecting a plurality of remote users to a
central processor such as the host 10.
The OS and CP are so structured as to permit the system of FIG. 1 to
operate in a mode that allows any number of active users to execute
application programs concurrently and to interact with the programs during
execution. In this respect, a plurality of application programs, each under
the control of one or more users, can be time-interleaved or executed in
parallel in the operations of the host computer 10.
For further detail, the resource complement of the workstation 16 is also
shown in FIG. 1. The workstation includes a terminal 31 having a CRT
display 32 and an alphanumeric keyboard 34. A cursor control input device,
commonly called a "mouse," is indicated by 36. The keyboard 34 and mouse 36
are representative of input devices that permit a workstation user to gain
access to, and use an application program in the host computer 10 through
the distributed computation system of FIG. 1. Alphanumeric keyboards are
standard devices that provide input parameters to the system in the form
of codes in response to depression of keyboard keys (called "key
strokes"). The keyboard can be used for inputting alphanumeric data or
commands corresponding to function keys on the keyboard.
The mouse 36 is a conventional locator device which is moved on a surface
to provide location and travel parameters for moving a cursor on the
screen 32. As is conventional, the mouse 36 includes one or more control
buttons which can be depressed for executing such well-known functions as
the "pick."
The display screen 32 can comprise any of a host of scanned devices which
present to the user graphical information in the form of figures and text.
The minimum complement of input and output devices specified for the
workstation 16 of FIG. 1 provide a man-machine interface between the user
of the workstation 16 and the system of FIG. 1. It is at this interface
that the user selects an application program suited for his present needs
and used the input and output devices to communicate with and use the
program in an interactive mode.
FIG. 2 illustrates in greater detail the interrelationship of the hardware
and software constructs included in the workstation 16. Also illustrated
by means of FIG. 2 is the indeterminate message passing delay that so
adversely affects application system echo response in the prior art.
Finally, FIG. 2 illustrates the interconnection of the invention with the
prior art constructs embodied in the workstation 16.
In FIG. 2, the workstation 16 encompasses the display 32, keyboard 34, and
mouse 36 already identified in FIG. 1. In addition, a direct access
storage facility (DASF) 38, which can comprise, for example, a disk
storage mechanism, is also illustrated. These hardware devices are
integrated into the distributed computational system by means of
workstation software structures, including a software operating system
(OS) 40, input drivers 46 and 48, and a display service 50.
The operating system 40 is conventional and can comprise, for example, the
UNIX/VRM combination described above. The input drivers 46 and 48 can
comprise conventional software processes, which are commonly termed input
handlers or drivers. Of course, the input driver 46 translates the
physical manipulation of the keyboard by the user into input parameters
for an application program in the host computer. Similarly, the input
driver 48 converts the manipulation of the mouse 36 and its buttons into
application program input parameters.
In the prior art in which echoing is controlled by the application program,
system responses, both computational and echoing, are returned from the
application program as output parameters, which are fed to a conventional
display service 50. The display service is a software construct for
converting the output parameters into the control signals that cause the
display 32 to present application responses visually to the user.
In the systems employing operating system echoing, the response functions
would be in the form of a driver-type software construct responsive to the
operating system and located between the operating system and the display
32. Hardware echoing would require a direct echo path connection between
the input drivers 46, 48 and the display 32.
In conventional distributed computational system structure, the operating
system 40 acts as the parameter interface between the workstation
resources and the resources of the host computer 10. In this regard, the
operating system 40 would include a construct for message-passing to
support data interchange traffic between the workstation 16 and an
application program in the host computer 10. The construct also supports
message-passing between the local processes in the workstation 16.
Characteristically, communications with the host computer 10 are
facilitated by the communication service 24, which also serves all of the
other workstations in the distributed computational system. Each
workstation encounters an unbounded delay time in exchanging messages with
a host computer application program. The delay time can be understood by
reference to FIG. 2 where a first delay time T.sub.1 is encountered when
the workstation 16 has to contend with other workstations for a
communications path through the service 24. Next, messages from the
workstation that are communicated to the host must compete for host
resources. In this regard, the host computer may have a number of
different application processes underway in various stages of completion.
In order for the messages passed to the application process of interest to
the workstation 16 to be processed, the application program must compete
with these other host processes for available storage and computational
resources of the host computer 10. This contention time is denoted as
T.sub.2. Finally, the roundtrip for a message and its response from the
workstation to the host and back again to the workstation consumes a third
time T.sub.3. Thus, the total delay between a user-initiated action at the
workstation interface and the response the action stimulates from the
application program is T.sub.1 +T.sub.2 +T.sub.3. T.sub.1 and T.sub.2 are
indeterminate because it is never certain how many contenders there are
for resources. Therefore, when a user-initiated action is taken against
the keyboard 34 or the mouse 36, the time for a response to that action to
appear on the screen 32 is unbounded.
It should be evident that an indeterminate delay can be tolerated when a
user action requires computation or processing, since the application
program is at a distance from the workstation 16. However, when the user
action requires no computation by the application program and requires
only an echo response from the system to confirm the action, the system
delay can become intolerable. This is particularly true when the user is
moving a cursor by means of the mouse 36 or assembling a command in the
form of a character string by using the keyboard 34. In these cases, the
user requires immediate confirmation that the system has registered his
action so that he can immediately undertake another. For example, if the
user is entering a formula by means of alphanumeric keys on the keyboard
34, he will want rapid confirmation of the entry of each keystroke, which
will be registered by having the character corresponding to the actuated
key appear on the screen 32. Ideally, such response should be virtually
instantaneous; desirably, the time of such a response should not vary. In
this regard, the echo response should occur within a bounded response
time. Obviously, this cannot be achieved if the remote application program
does the echoing.
The invention overcomes the indeterminate response time problem of the
prior art system by providing an application protocol 52 and an echo
pathway 54 representing the connection of echo responses from the protocol
52 to the service 50. In addition, another pathway 55 represents the
transfer of application program computation responses to the display
service by the application protocol. The application protocol 52 is an
independent process that can be downloaded to the workstation 16 at the
time that the workstation is initialized with respect to the host computer
and an application program at the host is selected. Downloading, or remote
programming, is a well-understood process by which the host computer 10,
under the control of the selected application program, transmits the
interaction protocol as a series of commands to the workstation 16. The
workstation operating system can conventionally compile the commands as an
independent process and link it to the input drivers 46 and 48 and to the
display service 50. The protocol 52 is also linked to the operating system
40, although only for the purpose of communicating with the application
program at the host computer 10.
Alternatively, the application protocol can be stored together with other
application protocols in the storage facility 38 of the workstation and
retrieved when an application program with which it is intended to be used
is called at the workstation 16. At this time, the protocol would be
retrieved and activated by the workstation OS. In this case, the
application protocols can be entered into the workstation 16 by the user,
who would employ well-understood programming techniques to make such
entry. This would permit the user to tailor the protocols to the user's
personal requirements.
As illustrated in FIG. 2, the application protocol 52 receives all
application input parameters from the input drivers 46 and 48 and all
output parameters provided by the application program in the host computer
10 under the conditions set forth below. In addition, the application
protocol passes all output parameters, whether computational or echo
responses, to the display service 50.
Turn now to FIG. 3, which illustrates five independent processes: the two
input drivers 46 and 48, the display service 50, the application protocol
52, and an application program 53 in the host computer 10. The processes
communicate by conventional message-passing or other equivalent
inter-process communication paradigms. Functionally, the application
protocol is connected directly to the drivers, the display service, and
the application program. According to the invention, when input data is
generated by an input device, the associated input driver is activated and
will perform certain control functions on its associated input device and
extract input parameters and status codes from the device. The input
parameters are formatted and communicated to the protocol 52.
The receipt of data from an input driver causes the application protocol
process to be dispatched. In this respect, the protocol analyzes status
codes and input parameters and either sends parameters across the
communication network to the application program in the host computer 10,
or sends commands to the display service 50, or both.
The receipt of input parameters for the application program at the host
computer 10 will eventually cause dispatching of the application program
in the host computer, subject to the above-discussed communication,
network, and host resource allocation delays.
It is important to note that the application protocol 52 and application
program in the host computer 10 are considered to be asynchronous
processes executing in parallel. Parallel execution permits the echoing
functions allocated to the protocol 52 to proceed concurrently with and
independently of the execution of the application program, insuring the
bounded response of the echoing functions. This is important when a
user-initiated event requires both a computational response by the
application program and an echo response by the protocol 52. This may
happen, for example, when a user enters the last character in a character
string constituting a command mnemonic: the application program must
execute the command, and the user must be notified that the character has
been appended to the string. Thus, the protocol 52 provides a branch
directly to the display service 50 for the time-critical application
response paths and a branch to the application program in the host for
application code paths that are not time critical.
In FIG. 4, and in the explanation which follows, it is assumed that the
application program selected by the user of workstation 16 is a
"spreadsheet" program which displays output parameters for the user's
inspection in a multi-dimensional matrix of "cells" on the display 32.
(Such a cell is indicated by reference numeral 56 in FIG. 2.) Each cell
constitutes a work area used for echoing to the user his progress in
inputting and editing data and/or formulas. As is known, the user
indicates which particular cell of the spreadsheet he desires to use by
moving a cursor (reference number 58 in FIG. 3) to a position on the
screen associated with the cell. When the cursor is moved to the cell
position, the cell is highlighted, usually by inverting the video signal
for the cell. Conventionally, each cell has associated with it data
constituting text, or a parameter in the form of a number or formula. When
a cell is highlighted, the application program assumes that all user
actions following the highlighting are to be taken against the data
contents of the cell. Thus, for a highlighted cell, a parameter value or
formula can be changed by user operation of the keyboard.
Characteristically, spreadsheet programs also provide a status area in the
spreadsheet display which contains status area relevant to the highlighted
cell. Commands are input to spreadsheet programs by the use of command
keys or command mnemonics entered by keyboard. In most cases, the echo to
the user of command invocations is provided in the status field of the
spreadsheet display. The spreadsheet program typically distinguishes
between cell selection and cell content editing on the one hand and
command invocation on the other by means of a status code that is set by
conventional processing means in response to user actions. When the status
code indicates the first set of actions, it is implicit that echo-type
responses are to be provided to the user. On the other hand, for the
second type of action, computational responses are expected.
FIG. 4 illustrates a flow chart embodying, at a high level, the behavior of
the application protocol 52 for a spreadsheet program in response to both
types of user actions. The application processing paths which merely cause
screen changes (cursor movement, cell highlighting, and text, data, or
formula editing) have been extracted from the main body of the spreadsheet
application program and placed in the application procedure 52. Since these
are the actions for which a bounded response time is required, they are
considered to be time-critical data paths and are found on the right-hand
side of the dashed line 59a and the left-hand side of the dashed line 59b.
In FIG. 4, the processing paths for actions which cause a re-evaluation of
the spreadsheet or some other computation on the spreadsheet to take place
are shown between the dashed lines 59a and 59b. However, those parts of
these paths which require echoing by the display are extracted into the
procedure of the application protocol.
In operation, the procedure of FIG. 4 receives inputs from the keyboard
driver 46 and mouse driver 48. Initially, the application protocol will
determine, on the basis of the current dialog state (which corresponds to
the aforementioned dialog code), the type of action to take in response to
keystroke codes provided by the keyboard driver. The machine state can be a
conventional data flag having two states in the spreadsheet application
context. The first state will indicate when the mouse cursor is currently
on a spreadsheet cell, in which case the protocol will interpret keystroke
codes as modifying the contents of the cell containing the cursor.
Otherwise, if the mouse is inactive and a special command input signal has
been received (such as one from the keyboard), the protocol will interpret
keystroke codes as commands or command mnemonics.
When determining action in the spreadsheet embodiment, the protocol
preferably identifies four kinds of functions, one of which will be
assigned to incoming keystroke code parameters; it selected the key action
in step 61. In the first function, keystrokes can be regarded as causing
recomputation and redisplay of the current spreadsheet tableaux.
Conventionally, such a function would be indicated by the code for the
ENTER or RETURN key on the keyboard. The second keystroke function path
would be associated with keystroke codes identifying a command environment
or designating a particular command. For example, it is often the case that
the C key of a keyboard indicates a command for copying a formula entered
onto a spreadsheet. In these first two keystroke cases, user actions cause
re-evaluation of the spreadsheet, or result in some spreadsheet computation
being undertaken. In the first case, the actions of the protocol are the
three procedure steps contained in the ENTER or RETURN branch of the
procedure. In the first step of this branch, the protocol constructs a
command for transmission to the application program and sends the
formatted command to the application program. This step is indicated by
reference numeral 62. In step 63 of the procedure, the protocol awaits a
response from the application program to the command. Although this is
shown as a discrete step, it is not necessarily the case that the protocol
will suspend all operations while awaiting the reply. It would be possible
to employ an operating system and protocol constructs that permit the
protocol to conduct other processes while the application program is
responding to the transmitted command. Whatever message-passing paradigm
is employed by the operating system, when the application program response
to the transmitted command is received, the protocol will undertake to have
the spreadsheet display changed to reflect the response (step 64).
At this point in the procedure of FIG. 4, the actions remaining to complete
the ENTER or RETURN branch of the procedure are identical to those taken in
response to a keystroke code indicating a command. These steps are
indicated by reference numerals 66 and 67.
In procedure step 66, entry of a keyboard command, or completion of an
event initiated by application program computation first involves
selecting and displaying a new set of prompts to the user in a command
area of the spreadsheet display. This is a conventional reaction of an
interactive application program to a user-initiated action that causes a
change of state in the system. See the Foley and Van Dam reference at pp.
57-59. Following the interactive reaction of the program, the dialog
status (machine state) code will be changed to control the protocol
response to future input from the mouse or keyboard. After this, the
protocol exits and waits for another input.
The third type of action function recognized by the protocol is taken in
response to keystrokes which modify or supplement text displayed in the
spreadsheet or the associated command and status areas. In this regard,
when the mouse cursor is located in a spreadsheet cell, the EDIT function
responds to keystrokes code parameters provided by the keyboard driver by
changing information in the cell or area. Thus, in the EDIT branch of the
procedure, each time a keystroke code is received, the code is collected
in a buffer in step 70 and the key code is echoed to the display screen in
step 72. Finally, the fourth function involves keyboard cursor commands
which move the cursor controlled by the keyboard. It will be evident that
the keyboard cursor is distinct and different from the mouse cursor and is
used primarily for data entry and editing. The keyboard cursor command
protocol function path requires that the protocol respond to keyboard
cursor input parameters by updating the location information establishing
the point at which the keyboard cursor is displayed and then echoing the
new cursor position by changing the position of the keyboard cursor on the
spreadsheet display. These two steps are denoted by reference numerals 73
and 74 in FIG. 4.
It should be noted that mouse cursor commands received from the mouse
driver 48 will also be echoed by the application protocol in a procedure
virtually identical with the CURSOR COMMAND branch of FIG. 4. In this
regard, the application protocol 52 receives inputs fr | | |
