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