Xref: utzoo comp.misc:4279 alt.bbs:259
Path: utzoo!hoptoad!amdcad!apple!bloom-beacon!mit-eddie!rutgers!mcdchg!ddsw1!karl
From: karl@ddsw1.MCS.COM (Karl Denninger)
Newsgroups: comp.misc,alt.bbs
Subject: Re: New Ideas in BBSes (No BS!)
Summary: What you want exists and works, you just need a _REASONABLE_ base
Keywords: BBS Client Server Network NOMSDOS
Message-ID: <2324@ddsw1.MCS.COM>
Date: 3 Dec 88 19:53:31 GMT
References: <1217@cps3xx.UUCP> <2093@uokmax.UUCP>
Reply-To: karl@ddsw1.MCS.COM(Karl Denninger)
Followup-To: alt.bbs,comp.misc
Distribution: na
Organization: Macro Computer Solutions, Inc., Mundelein, IL
Lines: 144

In article <2093@uokmax.UUCP> srpenndo@uokmax.UUCP (Sean Richard Penndorf) writes:
>
>You raise some very interesting viewpoints there, Robert.
>
>We at Ultimatum Software of Oklahoma are working towards some of those goals
>you just mentioned.  The problem of the graphics interface in BBS's before
>was the lack of computers which REALLY supported good graphics.  That is
>obviously changing very rapidly (ie, Macs, IBM PS/02s, Amigas, Atari STs, etc).
>The second problem to the graphics front end is the speed.  Unless you can
>some up with a very FAST system for the graphics, I feel most users will
>fall back to the standard ASCII type BBS.

Yep.  Then there's the kicker -- many people don't have systems that can
handle it, even today, and those that DO will require a specialized client
software package -- one for EACH type or brand of system you support.

Who's going to do the work to create/port these monsters?  This is not a jab
-- it's a serious question.  If you work with graphics-capable hardware you
know that everyone does it a little differently; some do it a LOT
differently.  There is NO standard at the moment.   What you are speaking of
is on the order of re-creating X-windows specifically for this task (ie:
simpler perhaps, but still a formidible programming job!)

Then there is the speed issue.

A graphics interface might be viable on a 9600-baud modem.  Unfortunately,
even today those are $500 and up; out of reach for the mainstream.  2400 baud
is reasonable, you can find those mail-order for around $100 if you're willing
to put up with horrid quality.

In reality most of our callers are at 1200 or 2400.  A few have an HST and
come in at 9600, a few (mainly Unix sites) come on using the Telebit.

In the next 2-3 years, we'll probably see $500 V.32 modems; 9600 baud full
duplex.  We might even see a $400 Telebit.  But 2400 baud modems will be
only $50-100 at that point -- which will the general public buy?  

Excluding 50% or more of your potential users is not a good move.

>ANother interesting feature you mention is multiple- conferencing.  Writing
good conferencing software will entail some very creative thought. 
>Especially when you add the term "multiple" to it, meaning that more than
>one conference can take place at one time.

Try AKCS or Picospan for starters.  Fully threaded, with multiple conferences
(how much disk space do you have for the messages?).

>But are these types of things being held back in the BBS community?

Nope.  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 (which means only an AT-class machine
with a couple of meg of RAM is required at the minimum) instead of MSDOS,
and you can purchase or scrape up from shareware/PD sources what you want 
right now.

>The tide is turning, but ever so slowly.

The tide IS turning, and not slowly at all!

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....)
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.
o An integral set of design decisions which permit and facilitate use of
  the system in a linked environment (ie: share conferences w/neighbors).
  I've seen several "hacks" [Fidonet anyone?] (and admit to writing one for 
  Tandy machines a long time ago); while those work they are far from "good".
  What's needed is a system which is efficient, doesn't allow "loops" to
  occur, and gets the responses and items to all connected sites.  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.
o Enough information must be kept around so people only have to look at what 
  is new; this implies variable-length summary files of some kind.  Users
  also should be able to tell the system to disregard a given topic of
  discussion (ie: forgetting an item exists).
o Enough control for the user 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.
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.
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).  The 
  standard items such as time limits should be enforced.  At the same time
  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.
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.
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.
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.
  For non-captive users, a nice touch is the ability to use external editors
  of the user's choice.
o A flexible external-package attachment system which is capable of
  preserving the security of the system for captive users (allowing you to
  graft on a 'C' or other language program to the conferencing system).
o User-selectable personalities (within system-manager definitions) are
  desirable; people like what they know, and being able to emulate some of
  the characteristics of their favorite environment is always a plus.
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.
o Most things should be redefinable by the administrator; commands, most 
  prompts, options, and help screens/pages/entries.


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.  

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.

Flames to /dev/null.  Questions and constructive comments to the mail
address below or call voice; people who want to check out conferencing 
first-hand can call the DATA number in the .sig (or vpnet, or igloo, or
chinet, or any one of many other sites).  The system below is 
PC-Persuitable (ILCHI).

--
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"