From: olsone@aix02.ecs.rpi.edu (Erik G. Olson)
Subject: Notes on BBS design
Organization: Rensselaer Polytechnic Institute, Troy, NY
Date: Sun, 23 Aug 1992 18:29:29 GMT

In article <PN0wPB4w165w@ersys.edmonton.ab.ca> andy-w@ersys.edmonton.ab.ca (Andrew webster) writes:
>About writing a BBS program, you would do a great service to the TI
>community if you developed a 100% assembly or c BBS program that
>supported full ANSI color and the option to go 40/80 col. We in Edmonton
>are currently writting a full blown BBS program based on the Telco
>modular concept, not Rambo as we had initially planed to do, but it is a
>slow process as we only have 2 busy programmers. Are you interested?

ANSI color and 80 col are really icing on the cake but still only 
feasible after that critical leap into full assembly. (or some exotic "XB2" 
environment.) We might debate the merits of putting a state-of-the-art BBS 
system back onto an actual TI (IBM's are somewhat characterless..) rather 
than this detail. Also I'm not volunteering for anything. But since talk is 
cheap, I'll talk about BBS programs, specifically my own, TI-Net (originally 
TI-SUB, which was a silly name if not forboding.)

The following were some of the goals I had in writing TI-Net (1985-1989):

1. Flexibility for messages. It should implement multiple message bases,
with separate privilege control on each one. Also private mail boxes,
and tracking of highest number read in each area.

2. Ease of maintenance. A text editor was the only tool needed. All files
were kept in D/F 80 (random access for userlist and bulletins) or D/V 80 
format. (logs, text files.) This was a great advantage during debugging.

3. Sysop sees everything on the user's screen. Also, the sysop can type
things for the user.

4. Hot keys. Chat key especially for opening chat mode at any point in
the program. Also keys to control such things as privileges, time, and
a hang-up key.

5. Customizability. The sysop should be able to write extensions to the
program and change just about every aspect of its appearance. This was
easy since the program lived in Extended Basic and relied on assembly code
for critical functions. A lot of "appearance" resided in text files--
including nearly all its text strings-- to make upgrades easier. External
programs could work in the BBS environment thanks to a subroutine library. 

6. Maximum use of resources. Nearly all filenames were set by the sysop,
so bulletin storage and other things could be spread across whatever
storage devices were available. I also worked with other sysops to get
the code to work with different modems and clocks.

7. Remote sysop. When logged in, sysop privileges enable all routine
maintenance-- upgrading users, garbage collection, log review, etc-- to
be done with BBS commands.

All of these goals were realized (in 85-86), along with file transfers and 
features like carrier detect (pin 8 to pin 19, which is rs232/2's dtr input.) 
The one goal never realized was netmail-- I wanted to interoperate with 
FidoNet. This became too problematic and eventually the memory was dedicated 
to other uses.

See Footnote #1.

Now here are some additional goals I came up with for a never-significantly-
completed all-assembly BBS program:

1. Fast file operation. TI-Net kept one file for each bulletin area or
file area, and about 12 other files. This was too many. It also required
periodic "message mashing" to clear out old bulletins (including
those already killed.) I designed a one-file storage system that would
hold every message in the system, require a minimum of overhead space,
and allow instant garbage reclamation. On the other hand, care would
have to be taken to make it resilient; a crash could cause great damage.

2. Maximum recordkeeping of read/unread messages. TI-Net provided 
highest read numbers for the first 10 areas. Sacrificing the DF80 format
(already done given goal 1) allowed for data to be kept in binary
format rather than text, greatly increasing the ability to keep more
information on each user.

A full accounting, a la Usenet news, is probably still impractical in
a small-storage system like a TI. You need a fairly big chunk of variable
size for such accounting. But I think I could make it happen, and have it
scale to the particular hardware.

3. Whither customizing? It is too much to assume that the sysop will be
able to recompile assembly source, or C for that matter, much less write
new code. You want a technique that everybody can access. Hence, the
likely solution of an interpreted tiny language that is easy to learn.
The program might even evolve into a hybrid of "BBS-tiny" and C or whatever. 
I have Marcus Weiand's Adventure Editor in mind as the model: the editor
actually decompiles the "pcode" executable into source for you. Of course
you need comments. This could be solved by storing comments in a separate
file and inserting references to them in the "pcode".

4. Whither tools? Obviously, the one-file non-cluttering message base,
and its corollary, namely that all that "BBS-tiny" code and its comments
needs to be stored in one single file, brings in the need for lots of
specialized tools. TI-Writer no longer cuts it as the all-purpose tool.
Actually this feature disappeared from TI-Net long ago as Matt Storm
took over the code and converted files from DF80 to IF80 to cram in more
information. (The code is presently maintained by Jesse Slicer.) So there
would need to be special tools for fixing/debugging the message base,
performing long-term de-fragmentation (possibly unnecessary), editing the
userlist, and of course editing "BBS-Tiny" code and copying/upgrading
segments of it.

If only the TI file directory had been designed differently, it would not
be necessary to have these one-file mechanisms. But as it is, searching
through the catalog of a huge directory is an unacceptable performance hit.
Essentially my idea was to build another file system implementation over the 
existing one. Fido/Opus programs keep every message in a separate file-- a 
real luxury made possible by the MS-DOS file directory, which penalizes 
performance in only a few non-critical places (such as garbage collection.)

5. Grab-bag: 80 col support, problematic (what if one side is incapable?),
full-screen editing (TI-Net had it in chat mode all along-- draw pictures!),
a revival of TE2 graphics and speech, possible succeeded by some other
method (NAPLPS?) since no one makes programs with TE2 graphics protocol 
anyway. Also exotic file transfer protocols: Zmodem, at least, and
then something like BiModem that allows simultaneous chat mode. A lot of
features would call for a new term program; if I had written the code
for the BBS I would have no problem giving the code to other term authors;
it's a matter of not wanting to have the burden of being a "term program 
mogul." Of course, I probably would have tried to get someone else to
write these features anyway.
 
Finally, the BBS would allow AppleTalk (or serial) connections to massive file 
storage kept under Macintosh System 7 file sharing. Just because I like the 
idea.

 **************************************************************************
 
Footnote #1: (on the core set of TI-Net features)

A thought: the BBS as we know it came to maturity around 1985, with these 
kinds of features finally becoming the norm everywhere. Since then, we've 
seen features like networking, multi-user nodes, and new forms of playing 
games, but the GUI (graphical user interface) revolution (Prodigy, etc) 
is the only really big (albeit underexploited) change since then. I could 
be wrong though, I don't get out of the Internet so much anymore.. I MUD 
more than I BBS, too.. Now here's a thought: a MUD made from TI mythology..

When I started, most of these features were unheard of in the TI world,
but rather common on other machines. (Fido, the Apple GBBS, and to some
extent that lousy crock C-Net.) TI-Net grew up along with all the others, 
but I constantly made sales based on features that other programs didn't 
have. Some of the competition then were Ralph Fowler's TIBBS (which was 
quite mature), 99BBS, John "99'er Magazine" Clulow's TI-COMM (which always 
seemed little more than a hardware experiment to me), TI-LINE (written 
entirely in XBasic!), and Monty Schmidt's Techie, which was born about the 
same time as TI-Net. Techie shared a lot of goals with TI-Net and Monty and 
I compared our solutions on occasion. Oh, and then there was T.I.T.S. (ha.)
I really have no idea what people use now; one program I haven't seen
myself is Citadel, but I think they borrowed the game room code from TI-Net
without ever telling me or Matt. Uncool.

Of course, the big day came when Paul Charlton gave out his Xmodem code
for BBS programs. Now *there's* a great service for ya.

 **************************************************************************

>Hmmmmmm...  I accept your "detailed" reason why you use F'Web 3.x.
>Have you tried Art Greens Rag Assemblerer/Linker, its small and top
>notch?
Not recently.. besides, GenProg is plenty of tool for me. Come to think of
it, isn't RAG a one-pass assembler with buffering, like GenAsm?

>About your Geneve, I believe there is hope yet for it now that the source
>is in the right hands...
I know.. I'm in on the buyout. (Thanks to Clint reposting the "final hour"
message.)

-- 
Erik G. Olson          =+ A kitten pawing a ball of wool, a cub wrestling with
olsone@rpi.edu         =+ another, experiment with gestures which they do not
                       =+ yet command. --Jacob Bronowski, _The Identity of Man_
Newsgroups: comp.sys.sun.misc