Xref: utzoo alt.bbs:274 comp.misc:4301
Path: utzoo!attcan!telly!evan
From: evan@telly.UUCP (Evan Leibovitch)
Newsgroups: alt.bbs,comp.misc
Subject: Re: New Ideas in BBSes (No BS!)
Keywords: BBS Client Server Network NOMSDOS
Message-ID: <437@telly.UUCP>
Date: 6 Dec 88 02:08:37 GMT
References: <1217@cps3xx.UUCP> <2093@uokmax.UUCP> <2324@ddsw1.MCS.COM>
Distribution: na
Organization: System telly, Brampton, Ontario
Lines: 171

In article <2324@ddsw1.MCS.COM>, karl@ddsw1.MCS.COM (Karl Denninger) writes:
> 
> [regarding availablility of good new conferencing software]
>
> You just have to look in the right places.  You start by taking your
> head out of the MSDOS world; like it or not, DOS just wasn't meant to
> support multiuser operation OR multitasking.  Yes, it can do both -- but 
> not well.
> 
> Start with a base of Unix or Xenix [...]
> and you can purchase or scrape up from shareware/PD sources what you want 
> right now.

What I don't understand is what everyone sees so wrong with Usenet news
software, with which many of you are reading these very messages? It doesn't
HAVE to be used for communications with other sites (though the added effort
is minimal, once the news software's running).

If one already makes the choice to go with Unix, what's wrong with using
established software, which is freely available in source? Usenet news
software, and associated Unix sources, make very good building blocks for
a BBS.

> My list of "must haves" for a "real" conferencing system:
> 
> o Threaded messages, so I can figure out what the #$@% is being said and
>   follow the thoughts.  (The admin has to be able to move things around with
>   reasonable facility, too....)

Done in rnews, which is even more difficult on Usenet since submissions to a
thread may come from many sources, and do not arrive synchronized according
to when they were first posted.

Granted, rn threads could use some work, and the program this is very
cumbersome and hard-to-learn, but perhaps someone could rework this into
something more manageable. Better than starting from scratch.

> o As many conferences as the person has disk space for, and an easy way
>   for users to select which conferences they wish to view.  Users should be
>   able to leave a conference for a few days or weeks and then return without
>   seeing everything again; the system must maintain the 'has seen' information.

Handled in Usenet newsreaders by maintaining a file for each user which
contains "last read" info for each conference (.newsrc).

> o An integral set of design decisions which permit and facilitate use of
>   the system in a linked environment (ie: share conferences w/neighbors).
>   [...]
>   To meet all of those goals you must be reasonable about how you connect
>   sites to the network AND the software must have been designed to handle the
>   linkage from the outset.

While Usenet B 2.11p14 has many warts, development on successors (Cnews,
Bnews 3.0, and GNUs) has been far from stagnant, and even the old stuff
accomplishes all of the above.

> o Enough control so the information is presented the way the user 
>   wants to see it (within reason).  Part of this is based on system layout;
>   multiple threaded menus that you must traverse are _maddening_ for 
>   experienced users and not that much help for novices.

That's the beauty of Usenet. A common back-end and file format, combined with
many different kinds of reading and posting front ends.

You want an icon-based news reader? God bless. What it means is that the
task of arranging and managing news (as opposed to reading, posting or
downloading) is ALREADY THERE.

> o Attached file areas, so you can use it as a UL/DL area (with quotas and
>   "smart" protocol support).  Users should be able to attach files to
>   replies and responses as well (as in "here's patch kit 3 for xxxx").  The
>   system has to be able to manage these files, and enforce download quotas.

What Usenet DOES lack is a front end for users which supports UL/DL protocols,
however, source for both Kermit and X/Y/Zmodem is available in source.
Shouldn't be to hard to build into a front end.

> o A secure captive user system so the host OS doesn't have to have 500 user
>   accounts defined (along with the problems that develop from that).

So the front end takes control of the dial-in port rather than, say, 'getty'.
Nothing special.  User accounts are stored in a simple ISAM file which makes
for quick response, and ISAMs are easy to come by.

Still, I'm not sure what's so bad about using the Unix password file for
user accounts if it's made bulletproof enough. A sloppy password can be
broken no matter how it's stored.

>   people with "shell" accounts must not be hindered in using the software;
>   'fer instance, a shell user should be able to "shell escape" from a
>   conferencing session, while a captive user obviously must not be allowed
>   to do this.

I personally have trouble with shell access to a BBS. Sounds too much like a
deliberate Trojan Horse, just waiting to be exploited. But certainly if a
BBS system stores a user's access level, that can be used to allow privileged
users access to a shell.

By using standard Usenet software, you can develop a tight front end for
non-privileged users, while allowing your shell users access through
conventional newsreaders.

> o A means to graft available job-scheduling software in the OS onto the 
>   conferencing software.  I don't want to be FORCED to expire old items at 30 
>   days, for example, nor do I want a limited set of options.  But the tools 
>   must be there to do what is needed from timed-execution scripts (ie: 
>   crontabs on a UNIX system), or provide the entire timed-execution
>   environment if the host OS can't handle it.

Check out Cnews expire.

> o Keyword-based help available nearly anywhere (ie: at "yes/no" prompts is 
>   a bit overkill, but it ought to work everywhere else).  The source files 
>   should be system-admin redefinable.

No question that this is desirable.

> o Context-sensitive editors available so people can see prior responses and
>   postings while composing mail and reply messages -- preferrably in the
>   same format as the user asked for while reading it in the first place.

You mean like the way I'm responding here, quoting you above while adding
my own comments?

Perhaps a split screen editor, which allows you to compose a message in one
window while reading the original postings, would be a nice idea. But that
is a part of the EDITOR, not necessarily the BBS program.

> o Methods to reply by and handle mail within the conferencing software are
>   also nice (although not _necessary_ within the framework of an open
>   discussion).  Once again, this has to work across different machines.

To me, there is a distinct line between private mail and public discussions.
Usenet combines the two well, and allows things like private responses to
public postings. Again, a non-shell front end for 'captive' users would be
desirable.

> o Most things should be redefinable by the administrator; commands, most 
>   prompts, options, and help screens/pages/entries.

Absolutely vital. The question is - what skills will the admin need to make
changes - text files, C code, shell scripts, etc.?

> There's several packages out there which can do most of this; some are
> shareware, some are commercial, you might even find a PD one.  

And one, Usenet, which while not PD, is damned close to it, and the authors
don't ask for money.

> I can't claim to be unbiased; we produce conferencing software for Unix 
> and Xenix systems.  I've tried to keep this from turning into an ad; a good
> chunk of it is what we've had suggested to us.

I'm also designing a BBS, which is little more than a multiple-expert-level,
menu/hot-key front end for existing Usenet software (and other commonly
available Unix sources, like Kermit and Xmodem). It's no major piece of
work, but it'll do what I think my users want. And it'll allow me to have
NO shell access, except to admin people. Shell access to outside users still
scares me.

I find that Usenet software, properly configured and administered, makes for
a very good conferencing system. It's not as straightforward as Karl's
software (which, admittedly, I know only by his descriptions), and Usenet
news readers can use some help (such as synchronizing threads). Still, I'm
more concerned about not tampering with something that works already.

And I have Usenet working...
-- 
Evan Leibovitch, SA of System Telly                   "I am most concerned that
Located in beautiful Brampton, Ontario, Canada          nobody will remember me
evan@telly.on.ca -or- uunet!attcan!telly!evan            when I am dead" - Anon.