home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / alt / bbs / 8248 < prev    next >
Encoding:
Text File  |  1993-01-29  |  2.8 KB  |  62 lines
  1. Newsgroups: alt.bbs
  2. Path: sparky!uunet!news.uiowa.edu!hobbes.physics.uiowa.edu!news.iastate.edu!destroyer!gumby!yale!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!torn!csd.unb.ca!UNBVM1.CSD.UNB.CA
  3. From: T0FG000 <T0FG@UNB.CA>
  4. Subject: DTS-0001, the BBS <=> Doorware proposed standard
  5. Message-ID: <27JAN93.20508086.0080@UNBVM1.CSD.UNB.CA>
  6. Lines: 51
  7. Sender: usenet@UNB.CA
  8. Organization: The University of New Brunswick
  9. Date: Wed, 27 Jan 1993 22:59:20 GMT
  10.  
  11. Allow me to clear something up for Mr. Pirelli.  I have absolutely
  12. no objection to proposing standards or adopting already existing
  13. standards in any application.  I feel my contribution to the
  14. DTS-0001 proposal is in bringing about the inclusion of existing
  15. standards into it.
  16.  
  17. BUT - you have a MUCH larger picture of what you would like to
  18. standardize than the DTS-0001 standard was ever conceived of
  19. covering.  Allow me to reiterate a concept mentioned in another
  20. message: DTS-0001 ONLY affects the interface of the calling BBS to
  21. the external programs (or doors).  It is clear that this area is
  22. important to anyone running a DOS-based BBS.  Under other operating
  23. systems, this problem may already be sufficiently covered not to be
  24. the nuisance it is under DOS.  (An operating system that wasn't
  25. anticipated to be as popular and long-lived as it has been... it is
  26. here, and those who use it must live with it.)
  27.  
  28. If you wish to continue a thread that covers more general topics
  29. such as
  30. standardization of BBS design from the ground up, please remove the
  31. reference to DTS-0001 from the subject line to minimize confusion,
  32. except where its presence is relevant.
  33.  
  34. To summarize: this standard is not intended to affect the operation,
  35. design or use of the target external BBS program, except its
  36. interface with the BBS software.  Mail standards issues are only of
  37. interest in the area of data type and size.  Interconnectivity
  38. issues are not relevant except where the BBS needs to communicate to
  39. an external program.
  40.  
  41. As for Fidonet being broken... well, its popular on 6 continents so
  42. far.  In addition, there are dozens of other smaller networks in
  43. existence
  44. as well.  The purpose of this standard is not to change any aspects
  45. of any of these networks, but rather to be compliant in terms of
  46. data types such that BBSes that must use dropfiles can communicate
  47. to the external program.
  48.  
  49. After all, the problem definition was to alleviate the problems
  50. introduced by the myriad of dropfile formats mentioned in the
  51. standard.  If the system you envision does not use dropfiles to
  52. communicate to external programs, you are probably reading the wrong
  53. document.
  54.  
  55. Will.
  56.  
  57.  
  58. ---------------------------------------- William Burrow
  59. Internet:  t0fg@unb.ca                      |
  60.            will@p1.f14.n255.z1.fidonet.org  | I'm not UNB, thats
  61. Fidonet:  1:255/14.1                        | someone else...
  62.