home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / amiga / datacomm / 7676 < prev    next >
Encoding:
Text File  |  1992-11-15  |  2.2 KB  |  49 lines
  1. Newsgroups: comp.sys.amiga.datacomm
  2. Path: sparky!uunet!convex!darwin.sura.net!spool.mu.edu!uwm.edu!rpi!pooler
  3. From: pooler@aix02.ecs.rpi.edu (Robert Peter Poole)
  4. Subject: Re: XPR-Bidirectional
  5. Message-ID: <80t19hb@rpi.edu>
  6. Keywords: bidirectional protocals
  7. Nntp-Posting-Host: aix02.ecs.rpi.edu
  8. Organization: Rensselaer Polytechnic Institute, Troy, NY
  9. References: <523@thunder.LakeheadU.Ca>
  10. Distribution: comp.sys.amiga.datacomm
  11. Date: Sun, 15 Nov 1992 17:58:31 GMT
  12. Lines: 35
  13.  
  14. In article <523@thunder.LakeheadU.Ca> tlbechar@thunder.LakeheadU.Ca (Timothy Lee Bechard) writes:
  15. >
  16. >    I was wondering if there was any development going on with regards to a
  17. >bidirectional XPR interface.  Looking into most of the ones that are available,
  18. >I've noticed that they are designed around a single "send" or "recieve"
  19. >standardized format.
  20. >    
  21. >    Tim Bechard
  22.  
  23. I think an XPR implementation of BiModem would be an excellent idea!  A lot of
  24. bulletin boards in my home state had implemented BiModem -- some because they
  25. (the sysops) realized that BiModem made it painless for users to upload as
  26. much as they downloaded, making quotas nearly obsolete, and others because
  27. limited connect times meant that a user using a unidirectional protocol such
  28. as Zmodem had no choice but to upload or download during a session, not both.
  29.  
  30. I am not sure if BiModem could be effectively implemented in the XPR standard.
  31. Part of the challenge is to figure out a workaround to all the issues of
  32. file selection on both ends; part is to figure out how to get the BiModem
  33. securities worked out in a reasonable fashion.  So really, if one wanted to
  34. implement BiModem, the programmer would have to write a whole suite of
  35. utilities to automate the process of choosing local and remote files, plus
  36. some engine (possibly in the XPR format) to actually do the transfers.
  37.  
  38. BiModem also requires pretty tight timings, since it is implemented on the PC
  39. (80x86) in highly optimized assembler.
  40.  
  41. Or maybe there's another bidirectional standard out there that folks would
  42. prefer to implement?
  43.  
  44. If John Radigan decides to add many more features after JRComm 2.0, maybe he
  45. could put BiModem support directly in the program as he did with X/Y/Zmodem.
  46.  
  47. Rob Poole
  48. pooler@rpi.edu
  49.