Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!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: <19920@usc.edu>
Date: 15 Sep 89 16:57:15 GMT
References: <1406@inria.inria.fr>
Sender: news@usc.edu
Reply-To: papa@pollux.usc.edu (Marco Papa)
Organization: Felsina Software, Los Angeles, CA
Lines: 72

In article <1406@inria.inria.fr| rouaix@inria.inria.fr (Francois Rouaix) writes:
|I don't  know how many  of you are interested in the XPR protocol
|for file-transfer protocols as shared libraries. I also think that
|Willy Langeveld does not read this group. However the problem I
|want to point-out may happen with other "shared-libraries".

Yes, he is not on usenet, but I usually feed him stuff, if it is related
to XPR.

|Let me remind this: XPR is (schematically) a specification for writing
|file-transfer shared libraries that can be called later from communication 
|programs independantly of the protocol.
|For the communication program, the library (read: any xpr library)
|defines only 4 functions. 

The 2.0 spec, just finalized and posted in bet on BIX, adds two functions that
allow "watchin" the comm line for "special character sequences" (like the ones
for Zmodem and CI$ autodownloads), support for DoubleTalk protocols, and
external terminal emulations (XEMs vs XPRs).

|As usual, and for C programs, there are stubs
|for calling these functions. As usual, and there lies the problem,
|these stubs use a GLOBAL _XProtocolBase.
|It is normal that a terminal program uses only one protocol at a time.

While this is true for protocols, it isn't any longer if one wants an 
external protocol AND and external emulation

|However, consider a multi-user BBS, designed such that all modules are 
|reentrant, so that all processes share their code and global variables.
|It is NOT possible then to write a download/upload  module according to
|XPR, or it means that all users should use the same protocol, just because
|the library base is a global variable.

Quite true.

|I can see that it's enough to change the stubs to solve the problem.
|However this means that the stubs must be recompiled and are not any more
|a link-time library as they used to be.

There you have it.  The XPR link-time library is a 'sample' for comm 
program writers.  The 2.0 spec cxlearly mention that if you want to 
do what you describe of want separately selectable XPRs and XEMs you have 
to set up other XPRxxxxBase pointers, one for each of the "concurrent"
things you want around.  note that this has ABSOLUTELY no infuence
on the XPR itself, which knows nothing about the way it is supported
inside the comm program.  The multi XPRxxxxBase solution is simple enough
that no change to it was decided. One of the reasons was that only 4 or
6 stubs are required, a practically insignificant amount of storage
overhead.

|Or would it be preferable to have a generic xpr.library, which in turns
|calls the xprXXX.library ? this xpr.library  would define the same functions
|but with a  new parameter UNIT, and also a new function 
|XPROpenProtocol("protocolname") returning a UNIT.
|It seems to me that this solution looks like the one that was chosen to
|manage the multiserial libraries.

You actually free to implement it that way if you want it. Taht's no
problem. I think that the multiple XPRxxxxBase solution is simpler,
but that's personal.

|Comments ? Other solutions ?

You got them.

-- Marco Papa 'Doc'

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