Xref: utzoo alt.bbs:249 comp.misc:4230
Path: utzoo!hoptoad!amdcad!ames!mailrus!eecae!cps3xx!usenet
From: usenet@cps3xx.UUCP (Usenet file owner)
Newsgroups: alt.bbs,comp.misc
Subject: New Ideas in BBSes (No BS!)
Keywords: BBS Client Server Network
Message-ID: <1217@cps3xx.UUCP>
Date: 1 Dec 88 18:42:47 GMT
Reply-To: raisch@frith.egr.msu.edu (Robert Raisch)
Distribution: na
Organization: Michigan State University, Engineering, E. Lansing
Lines: 212

--------------------------------------------------------------------------

[I have decided to post this as well as send it to 'chrisb' in the hope
that it might spur some conversation.]

--------------------------------------------------------------------------

Whew!  This had to go a Loooong way to get to you!  If it works, be sure to
at least mail me to tell me that you got it.

Anyway, you asked a question and I have a few answers that you might find
interesting....

The Next Step in Bulletin Board Systems
------------------------------------------------
(In my humble opinion...)

I really think that most if not all BBS soft that is popular these days
suffers from a lack of change.  If you sit back and look at it objectively, 
most BBSes support the same UserInterface/Options/etc. that the "Conference
Tree" BBS supported in the late 70's.  (Conference Tree, written in
Forth and running on CP/M class machines was the first publically
available BBS).

If you look at the rest of our industry, you see incredible change and
improvements.  But not in the area of BBS communications!  Why?

Well, I believe that it has to do with the fact that most BBS sysops
feel a necessity to support the "least common denominator" in terms of
user, (i.e. the user who has only a DUMB terminal).  Also a factor is
the sysop's lack of programming ability.  I have found that most sysops
are not programmers or designers.  They are mostly regular joes who are
interested in the "communication" aspect of BBSes.

It really saddens me to see what has NOT happened in the BBS community.

So, for the last few years I have been exploring alternatives.

What exactly is a BBS?  At the very least, it must support the following
features:
		Interuser mail.
		Multiple conferences.

These are the aspects that, I believe, make it a "communications"
medium.  These areas are the most used features of BBSes, with the sole
exception of "DOWNLOADING".

I really believe that UL/DL features are the bane of BBSes.  They take
up massive amounts of time and space, and demand a large amount of the
sysops time and energy to maintain.  If I were designing a NEW BBS,
(which I am, actually), I would not include any UL/DL capability except
as an afterthought.  My feeling is, there are far better machines out
there that support UL/DL quite adequately, and I am certainly not going
to attempt to compete with that.

So, we are really left with mail and conferences, or are we?

There are always "online games".  Another boondoggle, I believe.  What
can an online game on a BBS offer that can really compete with the games
that are currently avaliable on personal computers?  Multiple players.
And there again we have a serious "misuse of resources" problem.  WHat
is stopping your users from using your machine solely for games and
nothing else? Nothing.

Don't get me wrong!  I like a really good computer game as much as the
next hacker, but I think that the whole idea has to be re-thunk before
we can offer really interesting options to our users.

The Bottom Line
----------------------------------
I have an idea or three that I have been toying with for some time now,
and am actually thinking about implementing.

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?

	This BBS could present a User Interface that was tailored to the
	individuals own machine.  That would take advantage of graphics,
	should the users machine support them.  That would offer
	different "paradigms" to different users, while using the best
	features of the users own machine?

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

Science Fiction?  No.  I think I have a model that would offer all this
and more.  There are two "catches".

One:	It really means that some fancy programming needs to be done.  I
am currently doing a little of it, and plan on doing more, but would
like to get a group of people together to help design this.

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

The first catch only means that it will take some time to realize this,
while the second catch is a little more important.

I am interested in your views as to whether or not the second catch is
really THAT important.  If the terminal soft were to be distributed free
of charge to any interested parties, as well as the source, I think that
there might be some interest.

How is it done?
--------------------------

Very similiar to the way in which the Internet operates.  On a
CLIENT/SERVER model of interaction.

The BBS computer, (known as the SERVER), communicates with the users
machine, (the CLIENT), through a simple communications protocol that is
very similiar to Xmodem or Kermit.  Something like the TCP/IP protocol,
but much smaller.

The only real difference to the forementioned protocols is the addition
of a one byte "Channel Number".  Channels are a method of creating
multiple "virtual" communication channels over a single serial line.

The idea looks a little like this:

	[MAIL SERVICE]   [BULLETIN SERVICE]
	      |                |
	      +----+     +-----+	(Where a Channel connects to
		   |     |		 a Service)
		---------------
		   SERVER
		---------------
		 | | | | | | |   (Multiple channels)
		 | | | | | | |
		 -------------
                 Packet Driver
		 -------------
  		       |         (Single REAL Serial Connection)
		       |
		     MODEM

		     MODEM
		       |
		       |
		 -------------
		 Packet Driver
		 -------------
		 | | | | | | |	(Back into Channels)
		 | | | | | | |
		---------------
		    CLIENT
		---------------
                   |       |
		+--------+ |
		|MAIL    |---+
		|        |   |
		|        |   |  (Where a channel connects to a window)
		+--------+   |
		   |    CONF |
		   +---------+

A packet knows what channel it is supposed to be in and thus ends up at
either the proper window, (on the Client machine), or being sent to the
proper service, (on the Server machine).

The CLIENT runs the terminal software on his/her machine.  The software
dials the local SERVER and starts a session.  

The CLIENT requests that a mail service program run on channel one, a
chat program run on channel two, and the conference program run on
channel three.  At the SERVER end of a channel, there is a program
called a SERVICE, and at the CLIENT end of a channel is a window or a
full screen, or some other fancy user interface.

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!

If the Client supports graphics, we can have multi-user GRAPHICAL games
where the client saves an "Object Library" locally on his disk.  This
Object Library is used to hold various small pictures, or icons, that
are used in the game.  In fact, each player could have his/her own icon
that represents the player, and each player would get a copy of it to
display on his/her screen.  The image of a multi-user BBS game that uses
pictures of each player as game pieces, I think, is rather unique!

Well, I have rambled on quite a while now.  If any of this is
interesting to you, perhaps we could start a mail group to discuss these
ideas.

			Regards, Rob

P.S. If you have a quicker mail route to either uunet or mailrus, try
sending your reply back that route.  The way I had to get this to you
was really rather absurd.
-----------------------------------------------------------------------------
Robert Raisch - TechnoJunkie & UnixNut| UseNet: {uunet,mailrus}!frith!raisch
Network Software Group-301 Comp.Center| InterNet: raisch@frith.egr.msu.edu 
Michigan State University, E. Lansing | ICBMNet: 084 28 50 W / 42 43 29 N
-----------------------------------------------------------------------------
      The meek WILL inherit the Earth, (Some of us have other plans).
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
Robert Raisch - TechnoJunkie & UnixNut| UseNet: {uunet,mailrus}!frith!raisch
Network Software Group-301 Comp.Center| InterNet: raisch@frith.egr.msu.edu 
Michigan State University, E. Lansing | ICBMNet: 084 28 50 W / 42 43 29 N
-----------------------------------------------------------------------------
      The meek WILL inherit the Earth, (Some of us have other plans).
-----------------------------------------------------------------------------