Xref: utzoo alt.bbs:255 comp.misc:4275
Path: utzoo!utgpu!watmath!clyde!att!rutgers!labrea!mcnc!xanth!ames!haven!umbc3!uunet!steinmetz!davidsen
From: davidsen@steinmetz.ge.com (William E. Davidsen Jr)
Newsgroups: alt.bbs,comp.misc
Subject: Re: New Ideas in BBSes (No BS!)
Keywords: BBS Client Server Network
Message-ID: <12714@steinmetz.ge.com>
Date: 2 Dec 88 18:22:14 GMT
References: <1217@cps3xx.UUCP>
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Distribution: na
Organization: General Electric CRD, Schenectady, NY
Lines: 74

After running a number of BBS user agents, and spending two years
designing a new system, I'm also coding a BBS. Having spent all the time
I care to on design, I am not in any way soliciting any more input. I've
talked to a number of sysops and users, and done a VERY detailed design.

However, you are asking for input, so let me share a few general ideas
with you. First, if you are going multiuser, consider having a DOS
(single user) and UNIX (multiuser) version, rather than trying to get
DOS to support multiple sessions. It can be done, but DOS lacks the idea
of multitasking, file locking, validation, etc. This means that you get
to do that stuff yourself.

Consider the sysop first! Design the system so that it will take care of
itself to a reasonable degree. Again UNIX systems have a lot of tools to
do things like run backups and report generators at various times of
day, which can be done under DOS, but again without too much support
from the o/s. Be able to add and delete messages easily, and to take a
disk file which is not known to the BBS, and add it as a file or as a
message. The reverse is also desirable.

Consider if you want to have the sysop approve messages and/or files
before they are available to regular users. If you want this, make it
convenient. It really is a desirable feature, even if most people don't
use it.

When you delete files and messages, do you want to save them in a form
which allows reloading? If so you have to design your own backup and
restore format and programs, to save all of the header and description
info as well as the text, and of course some generation of a
description, preferably in a database, so you can reload. Sound hard to
do right? It is, but it will leave time for the sysop to do fun things
rather than routine stuff. After the first five years backups get REAL
boring.

Hint: if you want multi session under DOS there is a "communications"
region with some relatively portable calls to access it. THis might help
keep your ducks in a row.

User interface: at least three basic types, the type with all messages
in one big file, with consecutive message numbers, like CBBS; the type
with file and message areas each broken into groups, like RBBS and OPUS;
and the type with files attached to messages, broken into groups which
identify message and file topics, like Citadel and Magpie. Each of these
then has a threaded variant which allows chasing replies to a message.
This list is not complete, but you will have to make design decisions. A
good BBS will have several user agents.

Do you want to take advantage of neat graphics and color, windows and
other good stuff? Do you want to cut yourself off from the people with
the glass teletype, who may have lots of good ideas, even if they don't
have big bucks?

Storage of messages: one big file, one file per group, on message per
file? Take the easy way out and let the directory structure do most of
the work, or do it yourself for performance?

File protocols: what upload and download protocols do you want to
support? xmodem, ymodem, zmodem, kermit, window kermit, sealink, etc?
Build them in or run them a processes? Can you make several work at the
same time under DOS?

I have tried to give you some areas for thought rather than my decisions
on how to resolve these choices. I have spent a lot of time getting my
tools ready, including a table driven menu interface, a Btree database
manager, a screen interface, a table driven questionare interface, etc.
Each of these tools will be released by itself when I get the
documentation done. You will probably send a lot of time getting your
tools ready if you are going to "really do it right" as you intend.

Good luck.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me