rouaix@inria.inria.fr (Francois Rouaix) (09/15/89)
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.papa@pollux.usc.edu (Marco Papa) (09/15/89)
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 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
davewt@NCoast.ORG (David Wright) (09/16/89)
From what I saw in the XPRZ (XPR Z modems library), there is a seperate library for each protocol. That gets around the problem you talk about, as there is not one xpr library, but one for each protocol. According to his instructions, programs could look for libraries that start with "xpr", or could directly be configured for the xpr libraries that were available. Didn't you get the XPRZ library .zoo file? Dave
papa@pollux.usc.edu (Marco Papa) (09/16/89)
In article <1989Sep15.233027.7278@NCoast.ORG> davewt@ncoast.ORG (David Wright) writes: > From what I saw in the XPRZ (XPR Z modems library), there is a >seperate library for each protocol. That gets around the problem you talk >about, as there is not one xpr library, but one for each protocol. According >to his instructions, programs could look for libraries that start with >"xpr", or could directly be configured for the xpr libraries that were >available. > Didn't you get the XPRZ library .zoo? Sorry, David, but you are the one that should read the XPR protocol spec :-) Yes, there is a separate "external" XPR library for each protocol, but this is fine ONLY when a program runs a SINGLE external protocol at a time. When writing a BBS program that allows MULTIPLE connections (with multi-serial cards like ASDG's Dual Serial Boards, for example), the sources provided won't work because there is ONLY ONE XPRProtocolBase pointer that hold the library base address to access the 4 (now 6) XPR functions. What we (myself and Willy) suggest for that problem is an "array" of XPRProtocolBase pointers, one for each "port" that the BBS program supports. These pointers could be either statically or dynamically allocated (in the first case one has to limit the number of concurrent protocols). If this is done, then one user could use XPRkermit on serial.device, XPRzmodem on siosbx, Unit 0, and so on. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma, Diga and Caligari!" -- Rick Unland -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
papa@pollux.usc.edu (Marco Papa) (09/16/89)
In article <19937@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: [stuff deleted] > What we (myself and Willy) >suggest for that problem is an "array" of XPRProtocolBase pointers, one for >each "port" that the BBS program supports. These pointers could be either >statically or dynamically allocated (in the first case one has to limit the >number of concurrent protocols). Of course I forgot to mention that even the "stubs" have to be duplicated (and their name has to be different). -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma, Diga and Caligari!" -- Rick Unland -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
maniac@arrakis.nevada.edu (ERIC SCHWERTFEGER) (09/17/89)
It seams to me that someone mentioned that the problem with the global library pointer lies in the binding routines, not in the XPRlibraries themselves. Being an assembly language programmer, I don't use the bindings, but wouldn't it be possible to simply rewrite the binding routines to use non-global variables? I'm not sure how this would be done, but I'm sure some talented programmer can hack it out. ----- Eric Schwertfeger, maniac@arrakis.nevada.edu
rosenber@ra.abo.fi (Robin Rosenberg INF) (09/18/89)
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
userpap1@mtsg.ubc.ca (Paul-Andre Panon) (09/19/89)
-create a new set of stubs which take the library as first parameter and uses it as the library base, stuff it into A6, and do the JSR _LVO...(A6). No need for an extra library, put the extra step in the new C interface stubs! Should be a piece of cake.
userpap1@mtsg.ubc.ca (Paul-Andre Panon) (09/19/89)
-create a new set of stubs which take the library as first parameter and uses it as the library base, stuff it into A6, and do the JSR _LVO...(A6). No need for an extra library, put the extra step in the new C interface stubs! It should be a piece of cake. Sorry about the previous message but it's the first time I've tried to post this way
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (09/20/89)
In <20005@usc.edu>, papa@pollux.usc.edu (Marco Papa) writes: >Note that not only VLT but also A-Talk III, from Release 1.2 on, supports XPR. >We hope other 'commercials', shareware and PD comm authors will pick XPR up. >IMHO, XEM make good sense in a comm program, but not much in a BBS program. >The other way around as far as 'multiple XPRs' are concerned: they make a LOT >of sense in a BBS program; none in a comm program. Well, that sort of assumes that all future comm programs will be of the type: "one comm program per serial port". I wouldn't want to make that assumption. -larry -- The Mac? Oh, that's just like a computer, only slower. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
rouaix@inria.inria.fr (Francois Rouaix) (09/20/89)
In article <19920@usc.edu>, papa@pollux.usc.edu (Marco Papa) writes: > 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). Hmm .. Sounds great ! Is is the same spec. that may be found on Fish 247 ? I can't get to Bix from France, but now that we have a CBM BBS for developer support in France (also in other European countries I believe), I think it would be a good idea that this kind of documents should be forwarded regularly to these sites. I'm not sure what the exact procedure should be, but maybe we can work it out. In my opinion, the whole thing (VLT, XPRs) is really good work, and should be advertised. I'm anxious to see if XEMs make sense in a BBS context, as sure as XPRs do ! > [......] 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. [...] Ok I buy this solution. The library solution would introduce more stubs, and is in fact too heavy for such a light work. There are already so many "interfaces" because all specifications are based on parameter passed in registers, and most of the code is written in C. > |Comments ? Other solutions ? > You got them. > -- Marco Papa 'Doc' Thanks for these explanations. Thanks also to others who followed the discussion. -- *- 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.
papa@pollux.usc.edu (Marco Papa) (09/21/89)
In article <1410@inria.inria.fr> rouaix@inria.inria.fr (Francois Rouaix) writes: >In article <19920@usc.edu>, papa@pollux.usc.edu (Marco Papa) writes: >> 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). > >Hmm .. Sounds great ! Is is the same spec. that may be found on Fish 247 ? If the version of FF 247 is XPR 2.0 then it is the latest one. >I can't get to Bix from France, but now that we have a CBM BBS for >developer support in France (also in other European countries I believe), >I think it would be a good idea that this kind of documents should be >forwarded regularly to these sites. I originally e-mailed XPR 1.0 to comp.sources.amiga, and plan to do the same with XPR 2.0; just got others things to do, too :-) >I'm not sure what the exact procedure should be, but maybe we can work it >out. >In my opinion, the whole thing (VLT, XPRs) is really good work, and should be >advertised. I'm anxious to see if XEMs make sense in a BBS context, as sure >as XPRs do ! Note that not only VLT but also A-Talk III, from Release 1.2 on, supports XPR. We hope other 'commercials', shareware and PD comm authors will pick XPR up. IMHO, XEM make good sense in a comm program, but not much in a BBS program. The other way around as far as 'multiple XPRs' are concerned: they make a LOT of sense in a BBS program; none in a comm program. >Thanks for these explanations. Thanks also to others who followed the >discussion. You're welcome! -- Marco Papa 'Doc' >*- Francois Rouaix // We are all prisoners here, * >*- rouaix@inria.inria.fr \X/ of our own device * ^ ------------------------| ( Just heard Hotel California this morning on the radio. Still great as ever) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma, Diga and Caligari!" -- Rick Unland -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (09/21/89)
In <20033@usc.edu>, papa@pollux.usc.edu (Marco Papa) writes: >|Well, that sort of assumes that all future comm programs will be of the type: >|"one comm program per serial port". I wouldn't want to make that assumption. > >I really don't understand what you mean. Do you mean to suggest to use "more >than one comm program" per serial port? That of course works only if the port >is SHARED and the comm programs "collaborate" (i.e, only one receives at any >one time). Or do you mean "one comm program that controls two serial ports >at the same time"? If this the case, then it is much easier done by creating >a "reentrant" version of the comm program (easily done today with Lattice, not >MANX). In that case, running multiple instances of the comm program, each one >using a different port, will have the same space overhead as running one copy >that controls multiple ports. With today's programs that support multi-serial, >each instance of the program will allocate its own 'code' segment. That might >change sometime soon :-) 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. -larry -- The Mac? Oh, that's just like a computer, only slower. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
papa@pollux.usc.edu (Marco Papa) (09/22/89)
In article <770@lpami.wimsey.bc.ca| lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: |In <20005@usc.edu|, papa@pollux.usc.edu (Marco Papa) writes: ||Note that not only VLT but also A-Talk III, from Release 1.2 on, supports XPR. ||We hope other 'commercials', shareware and PD comm authors will pick XPR up. ||IMHO, XEM make good sense in a comm program, but not much in a BBS program. ||The other way around as far as 'multiple XPRs' are concerned: they make a LOT ||of sense in a BBS program; none in a comm program. | |Well, that sort of assumes that all future comm programs will be of the type: |"one comm program per serial port". I wouldn't want to make that assumption. I really don't understand what you mean. Do you mean to suggest to use "more than one comm program" per serial port? That of course works only if the port is SHARED and the comm programs "collaborate" (i.e, only one receives at any one time). Or do you mean "one comm program that controls two serial ports at the same time"? If this the case, then it is much easier done by creating a "reentrant" version of the comm program (easily done today with Lattice, not MANX). In that case, running multiple instances of the comm program, each one using a different port, will have the same space overhead as running one copy that controls multiple ports. With today's programs that support multi-serial, each instance of the program will allocate its own 'code' segment. That might change sometime soon :-) Could you elaborate? -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma, Diga and Caligari!" -- Rick Unland -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (09/22/89)
Oh, what a tangled web we weave.... In <20058@usc.edu>, papa@pollux.usc.edu (Marco Papa) writes: >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' Yes, I have read the spec, several times. I was not commenting, in particular, on the XPR spec itself, but rather, on the comments by you in the posting I was replying to, wherein you said things like "it doesn't make sense to have more than one... <whatever> in a (comm | BBS) program. It was an observation, pointing out that it might indeed make sense to have any configuration we can visualize, or even those we have not thought of yet. -larry -- The Mac? Oh, that's just like a computer, only slower. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
papa@pollux.usc.edu (Marco Papa) (09/23/89)
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 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (09/23/89)
In <20079@usc.edu>, papa@pollux.usc.edu (Marco Papa) writes: >That is definitely a comment on the XPRs and XEMs, not on the way the comm >program might use them. As I said it is the comm program that can decide >to use the XEMs and XPRs the way it wants. The spec does not "limit the >implementations of programs such as XEMs and XPRs" as far as your types of >'future' comm programs are concerned. This is a dead horse, and I refuse to beat it any more, so this will be my final comment on the matter. First, I used the phrase "such as", which you might attempt to discover the meaning of. Secondly, XPR's and XEM's was used in the general sense, and was not specifically directed at any given spec or implementation. You know of one such spec at this time. Don't assume that it is the final and only one. -larry -- The Mac? Oh, that's just like a computer, only slower. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
papa@pollux.usc.edu (Marco Papa) (09/24/89)
In article <775@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >In <20058@usc.edu>, papa@pollux.usc.edu (Marco Papa) writes: >>The current spec allows ALL of this. Time for a second reading of the spec? >Yes, I have read the spec, several times. >I was not commenting, in particular, on the XPR spec itself, Well, this is what you said: In article <773@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry s) writes: |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; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That is definitely a comment on the XPRs and XEMs, not on the way the comm program might use them. As I said it is the comm program that can decide to use the XEMs and XPRs the way it wants. The spec does not "limit the implementations of programs such as XEMs and XPRs" as far as your types of 'future' comm programs are concerned. > but rather, on the >comments by you in the posting I was replying to, wherein you said things like >"it doesn't make sense to have more than one... <whatever> in a (comm | BBS) >. It was an observation, pointing out that it might indeed make sense to >have any configuration we can visualize, or even those we have not thought of >yet. Agreed. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma, Diga and Caligari!" -- Rick Unland -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=