From: davidsen@ariel.crd.GE.COM (william E Davidsen) Subject: Re: BBS Development for Linux Date: Tue, 15 Jun 1993 15:48:13 GMT
In article <1993Jun14.011404.30035@news.weeg.uiowa.edu>, bmandrsn@news.weeg.uiowa.edu (Bryan M. Andersen) writes:
| If your looking for bbs softwear. My sugestion is to design the
| system from the ground up as a multiuser BBS and write your own.
I would have to agree, when I wrote MBS I spent about six months
developing the design, and wound up with 40+ pages of design
documentation. Even at that I had to make changes based on the overhead
on some systems.
| As an observer of a bbs which has grown from 20ish online at one
| time to over 400 now. Code design is very important. Lots of the
| available user increases were to little things like making the main
| bbs database a memory mapped file instead of normal file access
That's one approach, I used a B+tree and finally put the database
server at the end of a msg queue to eliminate the overhead of locking.
Even with all that, when I get about 40 users (386-16, 7MB memory) the
system may slow down.
| Now after touting the amazing things they've done with the code
| I have to say that it would be a bad idea to use thier code. It was
| a lousey design to begin with and it has many hacks which make it
| vary hard to port to a new system. Like it contains it's own network
| code to run telnet sessions. Or the total rewrites of the I/O
| libraries to remove memory allocation and to generally tune them for
| faster operation. Lots of stuf in the BBS code and the OS it's
| running on have been hacked to allow more users on at one time or to
| make the code more CPU efficient.
Amen! There are lots of things you can do if you only want to run on a
single o/s, but if you want to be portable you make some sompromises
where they don't hurt too much.
| If I had Linux up and running right now I'd be tempted to write
| a bbs for it. There are a few design ideas I'd do like use a database
| for messages as most tend to be rather small and wastefull if put in
| thier own files. Also I'd build it in a client/server form with
I found that the best results came from putting small messages in the
message file, and for large messages I put the filename in and set a
flag.
Other thoughts:
Allow many types of room access - MBS has the following (all
independent flags): hidden (not listed until you enter by name), secret
(never listed), adult (based on the adult bit in the user flags),
password, and private (with an access control list).
Allow many types of user access - I put read and write messages,
message editor, upload and downlowd on single flags rather than having
increasing levels of permission. I've never regretted the complexity.
Allow for help - MBS allows assistant sysops (the wairwitness) to do
most functions, and for room monitors (local deities) to handle
operations for both files and messages in a single room.
Automate sysadmin - allow for expire when too many messages (I did),
too much space in a room (it's in the plan but not implemented), and
expire by age. Decide if you want to be a front end for news and mail
(ala mbox), free standing but interfaced to news and mail (XBBS,
Citadel, etc), or just a free standing BBS (MBS). I admit that I have
left handles for news and mail interfaces, but a BBS is neither news nor
mail, and I will probably stop with the code which allows groups to be
shared between sites, using a builtin protocol.
Allow for multiple user interfaces - not all users like the same
thing. I did a tree structured menu and single large menu, and am in the
planning stage for an interface with the smarts in the users system,
cutting down on traffic. After that an X interface. I built the
capability all into libraries, so only the real user level stuff needs
to be written for a new look.
Hope some of these things prove useful, I've been running a UNIX BBS
since 1986, and they all seemed necessary when I decided to write my
own.
-- bill davidsen, GE Corp. R&D Center; 518-387-6489
TMR Associates, +1 518-370-5654
Custom programming, system configuration, data acquisition,
industrial monitoring and "smart house" environment control.