Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!bellcore!texbell!merch!cpe!hal6000!trsvax!johnm
From: johnm@trsvax.UUCP
Newsgroups: comp.graphics
Subject: Re: Graphical BBS ?
Message-ID: <194300059@trsvax>
Date: 18 Mar 89 19:04:00 GMT
References: <707T8M-KAUP@FINTUVM>
Lines: 90
Nf-ID: #R:<707T8M-KAUP@FINTUVM>:-21:trsvax:194300059:000:4182
Nf-From: trsvax.UUCP!johnm    Mar 18 13:04:00 1989


I too would like to know if such a standard has been defined.  But since I know
of none I spent a fair amount of time thinking about how one might go about
doing this.

My thinking ran along two channels.  One used X.PC (a protocol for error-free
transmission like MNP) because it had multiple logical channels built into the
one physical modem transmission channel.  It offered a lot of nifty features
because...
                A)  You could design some pretty free-form stuff for
                transmission of menus, mouse-events, etc. without fear
                of making a mess of the screen because one byte was
                trashed by line noise.

                B)  BBS's could use other logical channels to support
                background uploading and downloading.  You could read your
                mail and do lots more while you were picking up files.

                C)  It is a well documented standard and there are no
                royalties or fees involved for the use of it.  It also
                has a pretty small amount of overhead per packet.

                D)  It is packet based and should therefore be able to
                work well even over packet switched networks like
                PC Pursuit.

                E)  The actual design work was much easier if you had one
                logical channel that was for keystrokes, mouse-events,
                another for file transmission, etc.  The coding should be
                simpler too.

The other idea was to just come up with what would be effectively just a new
terminal definition.  This terminal would have escape sequences to describe
popup menus, drop down menus, mouse-events (sent to the host), and other
screen/interactive goodies.  I like this idea a lot less because it just
doesn't offer quite as much neat stuff.  However, it is a lot more practical.

I think you need to spend most of your time thinking in terms of two things.
One is, SPEED.  Transferring lots of showy crap around is going to bog you
down in no time if you do it every single time.  Just look at how much your
local BBS's slow down when they have a big colorful menu come up on the screen.
They spend half the transmission time just spitting out lengthy color change
sequences that could really be shortened considerably.

The other thing you need to think about is portability.  Before you add a
bunch of stuff to the protocol consider carefully, "What is going to happen
here when an Amiga owner (or Mac, ST, etc.) wants to implement this protocol?"
Will there be large hurdles to overcome?

A lot of my thinking was along the lines of speed and the number one thing that
I could think of was _ONLY MAKE THEM PAY ONCE_.  Here is my idea of a sample
session.  I have written out things that would really be represented by just
a few bytes in a packet to make things clearer.

HOST:                                    USER MACHINE:
Display Menu #47 for this board
at location (0,3).

                                        I don't have any Menu #47 for this
                                        board.

Ok, here it is...(*&(*&(*&*63247
%$$%%(*)*)*_)(_*%*...

                                        (Stores it away)
                                        Ok, I've got it and I've displayed it.

Waiting.                                Waiting.

                                        The user selected the third entry.

Ok, remove Menu #47 from the display.

                                        Menu #47 removed.

Ok, display Menu #56 for this board
at location (9,9).

Anyway, you get the idea.  By having the local machine store screens, menus,
etc. you could kill huge amounts of transmission time and still have nifty
interfaces.  If this technique were adopted by my local BBS's the performance
would actually IMPROVE because they all have some flashy (but slow) stuff in 
their interfaces.

Anyway, is there another group we could move this discussion to?  I would really
enjoy discussing this at great length but it seems to me that it is slightly
off the subject that comp.graphics is all about.  Just let me know where we
move it to and I'll be there.

John Munsch