Xref: utzoo alt.bbs:269 comp.misc:4293
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!rutgers!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: alt.bbs,comp.misc
Subject: Re: New Ideas in BBSes (No BS!)
Message-ID: <5435@cbmvax.UUCP>
Date: 5 Dec 88 20:02:50 GMT
References: <1217@cps3xx.UUCP>
Distribution: na
Organization: Commodore Technology, West Chester, PA
Lines: 87

in article <1217@cps3xx.UUCP>, usenet@cps3xx.UUCP (Usenet file owner) says:
> Keywords: BBS Client Server Network

> The Next Step in Bulletin Board Systems
> ------------------------------------------------
> (...) Let's play "what-if" for a moment.

> What if:
> 	A BBS could offer windows, icons, menus, popups, multitasking,
> 	online games, interactive communications (chat),
> 	context-sensitive help, and all of this while supporting
> 	multiple users on a machine not much more powerful than a
> 	standard IBM PC?

There's a commercial BBS service for Commodore C64 users called Quantum
Link that does a number of these kind of things.  While it's rather
primitive and doesn't offer multitasking (amazingly similar to the C64
itself), it does provide a somewhat windowed interface with pull-down
menu driven commands and context-sensitive help, along with graphically
oriented online games.  The C64 provides the editing facilities, graphics,
etc, much of which originates on the C64.  The host machine isn't
a C64, though this mechanism greatly lowers the load on the host, allowing
C64 owners to subscribe to this at a flat rate of around $10 a month.  

A grown-up version of this running on different machines would be very
interesting.

> 	This BBS could support, given the need, uploading and
> 	downloading, invisible to the user, and happening while the user
> 	was doing something else?

That would fall very neatly into such a system.  The Quantum Link software
handles all transfers to and from the C64 in terms of small packets.  Using
an extended sort of packet, a server could direct various packets to 
various places, such as file up/downloads, game windows, and virtual 
terminal windows.  Except for the game windows, I often use something along 
these lines for communication between my Amiga and our VAX here (a program
called DNET written by Matt Dillon).

> Two:	The user would run special "terminal software" on their own
> machine.

That's absolutely true.  And it is something of a limitation.  In the
case of Quantum Link, it means that you have to have a C64 in order to
use the BBS.  Now, they want it that way.  If something more sophisticated
were also made freely available to all different machines, this becomes
much less of a limitation.  In the context of something that you run on
your PC as a home BBS or whatever, it might make sense to have an all
ASCII or ANSI mode; the BBS software would certainly have no trouble 
asking the caller what kind of terminal it is.  Many of the advanced stuff
won't be available via ANSI terminal.  If the terminal software is
commercial, it would probably have to be pretty good to convince BBS 
folks to switch over to it; there are 100s of other places I can call
without a $50-$100 investment.  But if you're offering additional
services, like talking and DLing at the same time, or interactive games,
or even some of the other things that the Quantum folks have been 
successful with (ease of use, cost vs. CIS or PLINK or BIX), it could
be a winner.  And if the protocol is publically defined, free versions
of the software will no doubt be written for all the popular machines.
Those could be the first thing you're offered as you dial in with an
ANSI terminal.

> How is it done?
> --------------------------
> 
> Very similiar to the way in which the Internet operates.  On a
> CLIENT/SERVER model of interaction.  [...]

> This concept implies that multiple Client interfaces are possible.  So,
> if I like a "Command Line Interface", (similiar to the way that standard
> BBSes work today), or a Graphical Windowing interface, or a "Glass TTY
> with Multiple Screens" interface, I can have it!

This is very much what DNET gives me on the Amiga, and as I understand it,
much the way DNET works (though I think it uses 16 bit ID packets).  So
I can have a few ANSI windows to my UNIX machine, maybe a Tektronics
window, and perhaps an upload or download going all at once.  It all
works through the DNET server, which starts up as a background task on
the Amiga.  Each client program on the Amiga register with the server,
and the server routes the appropriate packets to the appropriate client.
Much the same thing happens over on the UNIX side of things.

> Robert Raisch - TechnoJunkie & UnixNut| UseNet: {uunet,mailrus}!frith!raisch
-- 
Dave Haynie  "The 32 Bit Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
              Amiga -- It's not just a job, it's an obsession