Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcsun!sunic!tut!ra!rosenber
From: rosenber@ra.abo.fi (Robin Rosenberg INF)
Newsgroups: comp.sys.amiga.tech
Subject: Re: XPR protocol
Keywords: use in BBS
Message-ID: <154@ra.abo.fi>
Date: 17 Sep 89 21:21:55 GMT
References: <1406@inria.inria.fr>
Organization: Abo Academy, Finland
Lines: 37

In article <1406@inria.inria.fr>, rouaix@inria.inria.fr (Francois Rouaix) writes:
> ...
> 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.

It is COMMON that a library base is cached in a global variable in most
programs. The base does not *have* to be global. Just a long as you get the
right value in A6 when calling the routine. 

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

I (personal preference) would suggest the stubs are changed once only to add
the base as a parameter. 

	res = XPRSendFile(Proto[n],...)

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

Seems to me like crossing the river to get water.

---------
Robin Rosenberg, rosenber@ra.abo.fi
		 rosenbergr@linus.abo.fi