🚀 go-pugleaf

Hi,
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".

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. 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.

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.

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.

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.

Comments ? Other solutions ?

-- 
*- Francois Rouaix                 //       We are all prisoners here,       *
*- rouaix@inria.inria.fr         \X/           of our own device             *
*- SYSOP of Sgt. Flam's Lonely Amigas Club. (33) (1) 39-55-84-59 (Videotex)  *
Disclaimer: Opinions expressed are my own, not those of my employer.