QB-CIMR

 BBS: Inland Empire Archive
Date: 03-01-93 (16:00)             Number: 395
From: JIM LITTLE                   Refer#: NONE
  To: QUINN TYLER JACKSON           Recvd: NO  
Subj: QB-CIMR                        Conf: (2) Quik_Bas

QTJ> JL> Quinn:

QTJ> JL>    I have some questions about QB-CIMR.  Specifically, is there going
QTJ> JL> be any kind of automation (such as a script
QTJ> JL> language) for the BBS?  Ho

QTJ>Actually, I was thinking about that.  What kind of
QTJ>thing were you consideri


   Well, I've thought about a couple different ideas.  It all depends on
how complex you want the language to be.

The most complex, but most flexible, would be an actual interpreted
language to run the bbs.  A section to log on a user might look
something like this:

'Caller detected, beginning of script
let screenlength = 24     'Pause and wait for keypress every 24 lines
let pause = On
display "WELCOME.ANS"
Logon                     'predefined script -- perhaps 'LOGON.SCR'
cls
if mail username then
   display
      You have mail.
      Do you want to view your mail now?
   end display
   getchoice
   if choice = "y" then
      ...
   end if
else
   display
      You don't have any mail.
   end display
end if
...

The script would be stored in a seperate file which could be specified
by the sysop.  It would be interpreted as it was run, eliminating the
need for a compiler and another file.

   This method has the advantage of being highly flexible, giving the
average user the ability to design just the kind of bbs -they- want.
Suppose you (the sysop) don't want to require a user name.  Don't!  What
if you want to require -three- passwords?  Just insert into the script.
These kind of changes are likely difficult, if not impossible, on most
bbs's because they are hardwired into the system.  With a script
language such as this, the sysop may do anything they want.

   However, this method also has some important disadvantages.  First, a
complex script language takes time to learn, and some sysops may just
want to install the software, and start going.  Second, there are some
things which can be very difficult to program, even with a flexible
language.  These problems can be solved by creating predefined scripts
such as 'logon', 'checkmail', etc.  These scripts would be called like
subroutines from the main script.  In addition, the bbs could be
packaged with a sample script that would perform all the functions of a
'normal' bbs.  As the sysop became more familiar with the language, he
could tailor the sample to his own purposes.


   Although all this may seem to be a little more complex than
necessary, please realize that it would be completely transparent to
the average user.  All they would have to do is change the *.ANS
files to their preferance, and everything is up and running.
However, once they do see something thay want to change, the means
are available.  (Have you ever used something that is user
configurable, thinking that you can finally make things -just right-,
only to find out that it isn't possible with that program?  With this
kind of language, that wouldn't happen.)


Ok, there you have it.  How to change the world in 10 easy steps. :)
Assuming that you are convinced, you may be wondering 'Ok, its a good
idea, but is he up to it?'  My qualifications:  Nine years programming
experience in BASIC (starting with the Timex/Sinclair 1000 w/ 2K RAM
(!)); knowledge of Pascal, C++, Fortran 77, and rudimentary ASM; two
years of classes in the forementioned languages, with emphasis on
structure; my current (personal, not class) project: an interpreter
fairly similar to the one outlined above, which is mostly completed.
And of course, all the resources of Quik_Bas.

Well, that's just about all I have to say for now.  If you're still not
convinced, please tell me your reservations and I'll try to talk you
out of 'em. :)

-Jim


 * SLMR 2.1a * "Hi, I'm a tagline virus. Please copy me!"


--- WM v2.07/91-0012
 * Origin: Com-Dat BBS  Hillsboro, OR.  HST (503) 681-0543 (1:105/314)