Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!clyde.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!samsung!rex!wuarchive!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!unixhub!slacvm!wglp09
From: WGLP09@SLACVM.SLAC.STANFORD.EDU
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: HandShake 2.20c doesn't save External Protocol Path
Message-ID: <91050.110925WGLP09@SLACVM.SLAC.STANFORD.EDU>
Date: 19 Feb 91 19:09:25 GMT
References: <2534@shodha.enet.dec.com> <1826@public.BTR.COM>
Organization: Stanford Linear Accelerator Center
Lines: 20


      Actually, how external protocol configurations are saved is up to
the comm program. Since comm programs in principle don't know which protocol
is running at the time (except for the name), and since a new protocol can
come along at any time, and since there's no way to ask the XPR what its
current settings are, it is just kind of hard to have the comm program
take care of the default settings. The only way it can really do that is
by "explicitly" supporting certain XPR's. VLT for example "explicitly"
supports xprxmodem and xprkermit: VLT has menu items to change various
settings for these two and saves them in the VLT config file.
     For the general case, the XPR docs *suggest* to use environment
variables, though the comm program *could* in principle allow the user to
type in an init string for each XPR and save it in the config file, and
then use it whenever the protocol by that name is requested. But since the
init string depends on the XPR, the comm program can't make any assumptions
about it, and it will have to be typed in verbatim by the user.
     If there were ever an XPR 3.0, one of the new functions would be to
get an init string from the XPR for the current defaults.

     Willy.