home *** CD-ROM | disk | FTP | other *** search
/ Beijing Paradise BBS Backup / PARADISE.ISO / software / BBSDOORW / RADOOR30.ZIP / README.DOC < prev    next >
Encoding:
Text File  |  1994-04-10  |  8.2 KB  |  188 lines
  1. RADoor II, Quick and dirty beta docu:
  2.  
  3.  
  4. WHY?!
  5. =====
  6.  
  7. Simple, the RADoor toolbox started it's live as a bunch of routines to write
  8. the votedoor program. My first door-program ever. It continued to grow as
  9. doors saw the light. At the point that it was mostly bugfree (as bugfree as
  10. a toolbox can get) I released it as RAdoor20.zip. Well, some improvements,
  11. suggestions etc. And I ended up with RADoor23.zip, a huge (168Kb) toolbox
  12. with lots of whisles and bells.
  13.  
  14. BUT as it goes with this kind of development, RAdoor became a mess.. The
  15. basic RADOOR.PAS file became to big to maintain in a decent way.. Worse, I
  16. couldn't even add comments due to tp5.5's filesize limit..
  17. Further I found it almost impossible to change at a more fundamental level
  18. due to the side-effects.
  19.  
  20. So it became time for ACTION..  This time I knew better what I wanted from
  21. a doorwriters toolbox, discovered the joys of objects (Note: I'm not talking
  22. about oops! But the Object way of keeping fields and methodes together is
  23. a real nice way to keep programs readable and maintainable!) and started to
  24. use userhooks in the form of procedural variables.
  25.  
  26. So I started from scratch (almost..;) to write myself a new RADoor. But first
  27. of all I made up a plan.. Yep, specifications.. Analyzis.. and all that other
  28. stuff my programming teachers used to make writing a simple program into a
  29. full featured hell.. But this time it was good to at least set some priorities.
  30.  
  31. Here's what I came up with:
  32.  
  33.  - Modular!  No longer all the stuff in a single file (Radoor) but spread it
  34.              over more TPU's this makes maintainance easier, (and upgrading
  35.              to TP 6.0's ASM also..)
  36.  
  37.  - Less RA dependant
  38.              Well, this needs some explenation I guess. Since I started to
  39.              write doors I regularly get request from ppl who find it a
  40.              pitty that my doors are only usable with RA. In RADoor the
  41.              depandancy on RA was completly intergrated, so there wasn't
  42.              a simple way to rewrite my doors for other BBS programs. (Maybe
  43.              Qbbs and SBBS would be possible, but the first changes tomuch
  44.              and for the second there was Richard Faasens utility.. )
  45.              Anyhow, this problem is solved now in a way. It's easier to
  46.              make RADoor work for other BBS programs too.
  47.  
  48.   - More sysop control
  49.              In RAdoor there was only a very basic sysop control. only
  50.              a statusline with some info, and an option to shell to dos or
  51.              to toggle the local noise. Here again, due to the intergration
  52.              things weren't that easy to change.
  53.  
  54.   - Compatability
  55.              Well, this was a though one. Should the new RAdoor be compatible
  56.              with the old RAdoor....  Of course it shouldn't have less
  57.              possibilities, but in the same way? I decided that making it
  58.              better was more important than making it 100% compatible.
  59.              This means that the basics are all still there.. But f.e.
  60.              WritelnF(Foss,'') has changed into Foss.WriteLnF('')
  61.              This is simple search and replace, but other things have
  62.              changed too. As long as your programs are well designed,
  63.              updating shouldn't be tomuch troubles.. (I did Cookie and
  64.              RA-pong in a few hours while debugging the new code)
  65.              If not.. Oh well, maybe this is the right time to rewrite
  66.              the program from scratch and MAKE it better to maintain. (as
  67.              I have to do on trivia..;-) If not, stick with RAdoor2.3
  68.              as it's almost bugfree (I only know a few small ones)
  69.              And I intend to give a ZIP file with the source together with
  70.              the source of the new RAdoor anyhow (for registered users..)
  71.  
  72.  
  73. Well. That were the major points.. Here are the new files with a
  74. short description:
  75.  
  76.  
  77. ANSIMUS.PAS   |
  78. DRIVER.PAS    | Nothing has changed here, only a few little bugs removed.
  79. DRVDEMO.PAS   |
  80.  
  81. DESQVIEW.PAS
  82.     The desqview routines. This unit contains the headers for DESQVIEW.ASM
  83.  
  84. DOORSYS.PAS
  85.     The lowlevel door functions. Display a file, show a textfile etc.
  86.     Usable for all kinds of BBS programs.
  87.  
  88. FILEOBJ.PAS
  89.     A very lowlevel unit for working with typed files. Makes it easy to
  90.     work with buffered input, apply record and file locking etc.
  91.  
  92. FILTER.PAS
  93.     An demo/default output filter unit. In the new toolbox all output runs
  94.     (optional) through a filter to translate codes into ANSI/AVATAR or to
  95.     filter them out. Filter.pas defines a colortable for the door and a
  96.     filter which translates codes in an output string to the correct
  97.     ANSI/AVATAR codes It also handles ClrEol and brackets translations.
  98.  
  99. FOSSIL.PAS
  100.     This is the main unit of the toolbox. It handles all the I/O, timing
  101.     and carrier checking and includes userhooks for the statusline, the
  102.     output filter etc.
  103.  
  104. FRAME.PAS
  105.     A door framework. With this framework writing an door for RA is only a
  106.     matter of writing application code. Of course only defaults are used.
  107.     You can change everything you like as soon as you feel at ease with the
  108.     toolbox.
  109.  
  110. GLOBINFO.PAS
  111.     This is an important file. To make the toolbox usable for other BBS
  112.     systems, the GlobalInfo record defined in this unit is used by all the
  113.     other units..
  114.  
  115. LOWLEVEL.PAS
  116.     LowLevel functions. These have nothing to do with doors especialy, but
  117.     are used by the other units. Things like path handling, conversion
  118.     etc.
  119.  
  120. RA.PAS
  121.     This is the only unit that directly works on the RA system files.
  122.     It's intended to fill the global info record in the GlobInfo unit.
  123.     It also includes the BBS dependent routines. For example, for reading
  124.     and sending online messages and updating the exitinfo.bbs
  125.  
  126.  
  127. USERHOOK.PAS
  128.     This unit contains code to use with the userhooks in the fossil unit.
  129.     It implements my statusline and sysopkey handler. Of course, you can
  130.     write your own. This one is only to get started. (although it's good
  131.     enough for me..;-)
  132.  
  133.  
  134.  
  135. The philosophy behind the new RADoor.
  136. =====================================
  137.  
  138. Well, as seen by the many units modularity is ok. The SysopControls are
  139. up to you, but the UserHook unit already includes a very reasonal set
  140. of sysop tools. (LockOut, HangUp, Inc/Dec time, User and System info,
  141. WarnSysop when user leaves door and more)
  142. Leaves the idea to easily create doors for other BBSses...
  143.  
  144. To make a door use more than one set of BBS configuration files is simple.
  145. Write a unit like the RA.PAS unit included in this package.
  146.  
  147. This unit should include at least:
  148.  
  149. - A way to read all the nessecary system files and extract info from them
  150. - provide sensible values for GlobalInfo fields which cannot be found in
  151.   the BBS's system fields
  152. - A logging procedure for writing info to the logfile.
  153. - the types which are probably needed.
  154.  
  155. you also want to provide global variables with the contents of the
  156. configuration files. In ra they are called RACOnfig and RAExitInfo
  157. Use a something alike naming convention to avoid confucion..
  158.  
  159. Since the globalinfo record is the only record used by all the other units
  160. (They don't use RA.PAS!) this is the only place where you have to interface
  161. with the BBS environment. Simple as that...;)
  162.  
  163.  
  164. What Else:
  165. ==========
  166.  
  167. Since I'm very busy these days, getting married in june (in greece. Imagine
  168. the paperwork for that!) I don't find as much time as I would like for
  169. RAdoor. That's why I decided to try an other way of support. I found
  170. Jos Bergman (the sysop of my support BBS) willing to provide me two
  171. area's, a file and a message area which will only be accesable for
  172. registered users. Here I put the finished products, units, docu etc.
  173. I decided to group things together, so there will be a basic unit with
  174. the basic stuff in RAdoor and seperate zippers for the add on modules
  175. like the messagebase stuff, the online editor etc. This way I can provide
  176. quick updates, bugfixes and additional units. Since I logon to RAccess Jaybee
  177. almost daily to look for mail, it's also the best place to report bugs, and
  178. discuss problems with me and the other registered users.
  179.  
  180. Please don't spread the files found in this area. They are only intended for
  181. registered users.
  182.  
  183. Gerhard Hoogterp
  184.  
  185.  
  186.  
  187.  
  188.