Path: utzoo!attcan!uunet!bloom-beacon!usc!pollux.usc.edu!papa
From: papa@pollux.usc.edu (Marco Papa)
Newsgroups: comp.sys.amiga.tech
Subject: Re: XPR protocol
Keywords: use in BBS
Message-ID: <20058@usc.edu>
Date: 23 Sep 89 05:21:24 GMT
References: <773@lpami.wimsey.bc.ca>
Sender: news@usc.edu
Reply-To: papa@pollux.usc.edu (Marco Papa)
Organization: Felsina Software, Los Angeles, CA
Lines: 40

In article <773@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes:
|In <20033@usc.edu|, papa@pollux.usc.edu (Marco Papa) writes:
|| Could you elaborate?
|Sure... it was more of a general observation than a specific recommendation for
|any given number of comm programs per serial port.
|What I meant was that on a machine like the Amiga, it is probably unwise to
|make assumptions about the number of comm programs it takes to run one serial
 ^^^^^^^^^^^^^^^^
|port.  This can work both ways, in that the number of comm programs running,
|may be more or less than the number of serial ports in use, and even further,
|that one comm program need not be a single, traditional, standalone program,
|but might consist of a single serial port handler and a number of
|XPR/XEM/XDISPLAY/XSCRIPTX/Whatever modules.
|
|All configurations are possible, and though some might be less probable than
|others, I don't think we should limit the choices of configuration by limiting
				 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|implementations of programs such as XEMs and XPRs; certainly not while we are
|just starting to develop the first building blocks.

Have you read the XPR spec?  "Current" XPRs and XEMs will allow the behavior 
you describe, if written as reentrant programs, like the 'xprzmodem.library"
that has been available so far as an external XPR. The current spec does NOT
"limit the choice of configuration" at all or makes any of the 'assumptions'
you make in your posting. The spec was created with features like the ones
you mention already built into it.  In fact it simply lists some
of the possible configurations that a comm program might want to use, but these
are certainly not the only ones one could come up.  Remember that the XPR or 
XEMs never directly act over the serial port, the screen or the keyboard, but
do it only through 'implementation hooks' included in the COMM code.  As far
as the XPR and XEMs are concerned they have NO idea of 'how many times they
are being run', who runs them or whether there are other XPR and XEMS running
on the same or other serial ports. The current spec allows ALL of this.  Time
for a second reading of the spec? :-)

-- Marco Papa 'Doc'
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
uucp:...!pollux!papa       BIX:papa       ARPAnet:pollux!papa@oberon.usc.edu
"There's Alpha, Beta, Gamma, Diga and Caligari!" -- Rick Unland
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=