home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / amiga / datacomm / 6188 < prev    next >
Encoding:
Text File  |  1992-09-08  |  2.7 KB  |  52 lines
  1. Newsgroups: comp.sys.amiga.datacomm
  2. Path: sparky!uunet!cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!ncoast!davewt
  3. From: davewt@NCoast.ORG (David Wright)
  4. Subject: Any desire for a standardized "C" door interface?
  5. Organization: North Coast Public Access *NIX, Cleveland, OH
  6. Date: Mon, 7 Sep 1992 02:40:31 GMT
  7. Message-ID: <Bu6srK.1LH@NCoast.ORG>
  8. Lines: 42
  9.  
  10.  
  11.  
  12.     I have been working on coming up with a standardized way for "C"
  13. programmers to interface to BBS systems without having to resort to using
  14. ARexx, or some BBS-specific (such as C-Net, Paragon/StarNet, etc) format.
  15. Right now I have it as a link-library, but I could convert is to a shared
  16. library if people thought that was needed.
  17.     Since my applications are basically multi-user games, rather
  18. than Sysop-oriented utilities, the functions that I currently support
  19. are things such as getting lines from the user, sending text to be displayed
  20. to the user, etc. although I do have a way to do things like read and/or
  21. lock the current user's configuration so that the door can access
  22. commonly used/desired information in a BBS non-specific manner.
  23.     Why would you use this rather than something like OwnDevUnit or
  24. by going through ARexx? Well, basically the trouble with OwnDevUnit is that
  25. it assumes the program is going to access the serial port, AND it requires
  26. that the application knows how to talk to the serial port. Both of these
  27. are bad assumptions, IMHO. To my way of thinking the door writer SHOULD
  28. NOT CARE (or KNOW) whether the door is being run over a serial port, a
  29. network connection, or locally at the console. You should not need three
  30. different doors to let you do this kind of thing. The BBS already KNOWS
  31. how to handle all of the above, and all a door should have to know how to
  32. do is to talk to the BBS. Thus (to re-emphasize the same point in a
  33. different way), the same door could work locally, over a network, over a
  34. serial port and with ANY BBS that followed the standard.
  35.     The reason for not wanting to use ARexx is this. Not everyone has it,
  36. and I don't think ARexx has any place as a part of a transport layer
  37. between user-interactive tasks. Would you want a 9600 baud download going
  38. through ARexx? I have no trouble with the idea of simple utilities being
  39. written for a BBS entirely in ARexx, but I don't think that any SERIOUS
  40. application, (or one that requires a lot of CPU overhead) should be.
  41.     So, what I was wondering was, would anyone (mainly people writing
  42. BBS software and/or door software) be interested in adopting some
  43. standard for C language access, and if so, would they be interested in
  44. taking a look at what I've got (freely distributable, even in commercial
  45. packages)? Or am I missing something stupendous in going through an extra
  46. ARexx layer which provides the same functionality?
  47.  
  48.  
  49.                     Dave
  50.  
  51.  
  52.