owner=Michael Grobe
%%owner_address=grobe@ukanaix.cc.ukans.edu
%%owner_info=University of Kansas, Academic Computing Services
link_delimiter=<


		    Executing Remote Applications

Lynx provides several methods for executing programs running on remote
servers.  These facilities are provided    to help integrate   certain
kinds of information into hypertext documents.   For example, consider
providing data about campus events through a hypertext document.  Most
users will not be  interested in the entire list  of  events, nor will
they want to list events occurring during the same time period.  These
conditions make a predefined hypertext calendar somewhat unwieldy, and
favor  (although   they  do  not   dictate)  an   interactive database
interface.

One way to implement such a system is  to define a  protocol that Lynx
could use  to  request calendar  information from  a calendar database
server.   This  approach was  not   taken, mainly because  it requires
either a single system of considerable generality (which would require
significant development   effort,  as  well  as  user   training),  or
encourages a  proliferation of special  purpose protocols  for various
event types and/or administrative units.

Instead,  Lynx provides a  communications channel  to database servers
that  interact  directly with  the user.   In  essence, Lynx becomes a
conduit between the user and a remote server.  (In X  windows terms it
becomes a display server.)   Information  providers  are then  free to
develop programs that display information in a way that best suits the
needs of their clientele.

Lynx  employs three  standard approaches to  remote program execution.
First, Lynx provides the RLOGIN local execution link.  An  RLOGIN link
instructs Lynx to open a connection to a remote system and then act as
a terminal  emulator until the  remote session is closed.   The syntax
for an RLOGIN command is

	RLOGIN  host  [-user=xxxxx]  [-password=yyyyy]

where hostname specifies the  remote system  housing the program to be
executed, the -user option is used to  specify the account holding the
program and the -password option specifies a password for the account.
Usually the program to be executed will be run as  the login shell for
the specified account  and there will be  no password required.  Users
who login will be able to execute no shell commands  since the program
to be accessed will be started as soon as  the user  logs  in, and the
session will be terminated as soon as the program is terminated.

To provide  a second  method   to launch a  remote  application,  Lynx
supports standard TCP/IP socket communications techniques to start and
exchange  information with  remote servers.  Each server listens  on a
defined port   on a server  system   until  it  receives a  request to
establish a  connection  from a Lynx  client  process.  Lynx  can open
connections to   programs  listening on  specific  TCP/IP   ports when
processing links like:

	link_delimiter   !  port@hostname   end_link_delimiter

When  such  a  link is activated,  Lynx  makes   a  connection to  the
specified port and assumes  that any  text sent through the connection
is intended for a VT100 display.  If Lynx can  determine that the user
is using a VT100 display device, the VT100  commands are simply passed
on  to the  user.     Otherwise, Lynx  converts   VT100 screen control
commands to commands suitable  for the display  device actually  being
used by the user (via calls to the UN*X curses library).

For  example, the  file below  gives users  access  to a collection of
event calendars spread across a number of servers:




            Welcome to the Campus Event Calendar Menu
        Please select an event database from the list below:


	<<!4718@ukanaix.cc.ukans.edu>General Campus Events

	<<!4377@admin.cc.ukans.edu>Important Academic Dates

	<<coll-cal@chomsky.ling.ukans.edu 70>Linguistics Department 
      Colloquies

	<<!events -display DISPLAY @kurexec.cc.ukans.edu -user 
      rexec >City and Regional Calendar




Activating the General Campus Events link would then invoke a screen
that looks like:



            Welcome to the Campus Events Server

             Press Return here to Show Events

           Starting search date:  Jul, 17 1992
             Ending search date:  Aug, 17 1992

                       Categories
   * Academic field                   * Museum gallery
   * Academic year                    * Music
   * Athletic                         * Other cultural
   * Ceremonies, recognitions         * Parties
   * Club group meetings              * Recreational
   * Conferences workshops            * Service charitable
   * Film                             * Special academic
   * Holidays                         * Theatre
   * Lecture                          * Training events
   * Local area                       * University governance

            Categories with a '*' are selected.
       Enter 'a' to select all, 'n' to select none.
                  Enter 'q' to exit.


This screen is not a Lynx screen, but is displayed by the event server
running  on ukanaix.cc.ukans.edu.   The  user may choose  a  new  date
range, or a subset of the event categories supported, and then examine
the  list of events.  When  the user leaves this  program, by typing a
"q", control  is returned to  Lynx.  (Note   that Lynx commands either
will not   work, or  work differently,   while  the  event program  is
executing.)

Many  user programs can be   easily set  up  to communicate  with Lynx
through this interface.   On UN*X systems,  a program started by inetd
from  a script specifying  VT100  as the display device (using "export
TERM=vt100", for example, within a ksh script), will have its standard
output  directed to, and will   receive its  standard  input from  the
(remote) Lynx process.

Lynx itself may be started from inetd in this fashion, and  supports a
command- line  option (-term=)  that can be  used  to set its terminal
type to VT100 under these conditions.  For example, the link

	<<!lynx -term=vt100 startfile @ukanaix.cc.ukans.edu>

when executed by a Lynx  client could  start another  version of  Lynx
running   on ukanaix that would  assume  it was  talking   to  a VT100
terminal  so  that  the local Lynx client  could translate to whatever
terminal was actually being used by the user.

Programs not started by inetd can be set up to read directly from, and
write directly to sockets opened in response to Lynx connect requests.
For more information on setting programs up to run with inetd, see the
man files on UN*X systems.

At the  present time Lynx does  not provide  full  VT100 emulation for
non-VT100 terminals.  Additional capabilities will  be added  in later
versions.

Some information   providers may  have developed,   or wish to develop
database servers  that can  display   their information through  the X
Windows interface.  To  support this  interface Lynx provides  a third
method for launching remote programs via links of the form


	link_delimiter   !   program_path   program_arguments 
		@hostname    -user   login_name
			token_delimiter   character_count
				end_link_delimiter

When a link of this form is activated, Lynx  will essentially login to
the account  login_name on the  remote system hostname and execute the
program   in  the  file program_path.    The  arguments  specified  in
program_arguments will be passed  to  the program  when it is started.
The address of the user's X  windows server  will be used  in place of
the variable DISPLAY in a  link of this form.  This  allows a link  to
pass the  X windows server address  to the remote program through  the
program's argument list.  The user will then  interact with the remote
server through an X window.

The example Campus Event Calendar Menu file above includes the link:

	<<!events -display DISPLAY @kurexec.cc.ukans.edu -user rexec>

which instructs Lynx to login to  the account rexec  on the  system at
kurexec.cc.ukans.edu  and run   the  events  program  using   the Lynx
client's X windows address for any X windows displays.

To  grant access to all  users who may  wish to  use the database, the
account rexec would probably be set up to run without a  password.  To
limit its  use, the account would also  be set up to  run a restricted
shell  that allows only  approved applications  to run within it.   In
addition, the account would belong to no groups, own no file space and
prohibit su access.

Note  that  any character used  by  Lynx  to delimit link  information
(e.g., the link and target delimiters, the colon,  or  the at-sign (@)
appearing in a command to be executed must be preceded  by a backslash
(\).
