Xref: utzoo alt.bbs:283 comp.misc:4319
Path: utzoo!hoptoad!daisy!wyse!vsi1!ames!mailrus!ukma!rutgers!mcdchg!ddsw1!karl
From: karl@ddsw1.MCS.COM (Karl Denninger)
Newsgroups: alt.bbs,comp.misc
Subject: Re: New Ideas in BBSes (No BS!)
Summary: Usenet is nice, but designed for a different audience
Keywords: BBS Client Server Network NOMSDOS
Message-ID: <2398@ddsw1.MCS.COM>
Date: 8 Dec 88 18:11:25 GMT
References: <1217@cps3xx.UUCP> <2093@uokmax.UUCP> <2324@ddsw1.MCS.COM> <437@telly.UUCP>
Reply-To: karl@ddsw1.MCS.COM(Karl Denninger)
Distribution: na
Organization: Macro Computer Solutions, Inc., Mundelein, IL
Lines: 181

In article <437@telly.UUCP> evan@telly.UUCP (Evan Leibovitch) writes:
+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).

Lots of things are wrong with the Usenet software.  While I'm very much in
the various author's debt for this code we all know, love, and use, it's
really a quite-horrid mess.

Ever try explaining Usenet, how to use the various readers, reply to mail,
edit a newsgroups line, on and on ad-nauseum to a rank computer beginner?

+> 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.

Rn has a _horrible_ means for doing this.  In addition, since the net
software itself doesn't respect any kind of threading, we have these
enormous quoting problems.... in some cases, half of our traffic on a given
day begins with ">"!

+> 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.

The front-ends we have now, quite frankly, are crippled due to the internal
structure that Usenet uses.  'rn' is a mess and does all kinds of wierd
things to perform it's tricks (and has a hack or two in the news software
itself just for it's use :-)  Yes, it does work, but me gawed is it kludgy,
and more importantly, a pain in the neck for the administrator!

+> 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.

There's a problem with this; you have to be _real smart_ when your pieces
come in 50K at a time, and you have to get all  pieces before you have
something useful.  At least the net has a standard binary format (uuencode),
but what in the devil do you do with shar archives of source?

Transferring the postings raw to the end user is worse -- now the USER has
ot understand not only how to read and access the net, but the bits and
pieces needed to put back together these articles.

Easy for us, difficult for the average Joe who knows how to insert a floppy
in his drive and boot the PC (or type ATDTxxxxx to a terminal).

+> 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.

Not the point; Unix shell accounts have other problems which have to be
dealt with, including disk resources and a limited namespace (some passwd
files barf at 32K; Microport SV/AT is a good example!)

THAT particular problem with Microport makes a large system (500+ users) on
a '286 IMPOSSIBLE without some external help.

+>   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.

If the user came from the shell, he should be able to access the shell.
You've already granted him/her access to it in the first place.  For
non-shell users (captive accounts) you can't (and shouldn't) be able to get out.

+> 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.

Not desirable -- more like required.

Reading an entire man page looking for a command's description doesn't 
cut it anymore.

+> 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.

Ok, so now go back (while EDITING) and reference the ORIGINAL POSTING that
started this thread.  IMPOSSIBLE with the current scheme of things!

Incorporating an editor (but not _THE_ editor) into the package makes it a
LOT faster; have you ever waited 30+ seconds for vi to start up on a slow
machine?  You don't wait like that when there isn't an extra "fork()/exec()"
to do in the meantime....

+> 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.

Yes, and in this regard the net does do a reasonable job; email is handled
without too much hassle.

+> 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.?

An admin shouldn't have to be more than proficient in an editor and reading 
(for the manual) to be able to configure things.

It is absolutely unacceptable to expect a user to know how to program in
order to be able to set up the system to fit their needs!

+> 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.

And is designed for a completely different audience than the typical "bbs"
user; the "pucker factor" for a new Usenet user is quite large.

For a computer professional this is easy; for a neophyte who just bought
his/her system at the local Radio Shack this is a VERY important issue!

--
Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl)
Data: [+1 312 566-8912], Voice: [+1 312 566-8910]
Macro Computer Solutions, Inc.    	"Quality solutions at a fair price"