Newsgroups: comp.sys.apple2
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!maverick.ksu.ksu.edu!unlinfo.unl.edu!hoss!greg
From: greg@hoss.unl.edu (Lig Lury Jr.)
Subject: Re: ACOS (WAS: Re: MD-BASIC (was:Re: Apple ][ BBS Software))
Message-ID: <1991Jun6.173827.2914@unlinfo.unl.edu>
Sender: news@unlinfo.unl.edu
Nntp-Posting-Host: hoss.unl.edu
Organization: GBBS/ACOS Sysop Support
References: <817@generic.UUCP>
Date: Thu, 6 Jun 1991 17:38:27 GMT
Lines: 73

sysadmin@pnet91.cts.com (Matthew Montano) writes:

>Just like to add several more things to the "ACOS vs. ProLine battle". Several
>points which are valid to ME as a sysop.

>ProLine, because of it's design, can support many different terminals. It has
>terminal emulations for maybe 20 terminals, as well as TTY.

Yes, that is another good point about ProLine.  However not all are
complete.  I use the PSE code ^R extensively to compress the amount of
time it takes for message headers to reach my users.  I may use a
long-duration but inaudible tone command to delay their end for awhile
while I send stuff that I can't compress, but needs to be displayed
quickly.  Some of them are still at 300 or 1200 bps.

METAL does have extra emulations, but I can't remember the quantity or
names.

>ProLine, unlike most GBBS/ACOS
>systems, doesn't assume the type of terminal emulation. I don't use ProTERM,
>and a BBS shouldn't expect to use ProTERM.

I agree.  It is the same argument I have with systems that assume you have
the capability of displaying IBM graphics characters.  Everything should
have the capability of going to 7-bit-only ASCII, with no ESC sequences or
special-ability control-characters.  (Hyphenated to increase readability.)
One must please the users, or else they won't call.

>If these heavily modified ACOS boards require ProTERM, what about when I call
>the BBS from work with my Mac or IBM, or from an Alex terminal (Cdn's will
>understand).

This is a very good gripe about default emulations.  However, more and
more systems are going with an emulation detect before logging in, with
the capability of redefining your personal emulation.

>ProLine has the ability and performs admirably at supporting (and amazing) all
>types of computer users, from Amiga's to PC's.

TTY does this easily.  True, no whistles, just BELs, but it insures
compatibility.  Most of my code still outputs "vanilla ASCII", with only
the occasional trap for alternate emulations.  I believe in quality, not
quantity.

>As well, all the modifications to ProLine would likely be done with a standard
>text editor and standard text files containing config information or scripts.
>pro-generic was heavily modified when I ran it, not because it had to be, but
>because I had fun doing it... and I rarely modified line's of code, it was all
>scripts and configuration information.

So basically you weren't doing direct modification, but instead adding
things.  I use the term to refer to changes made to the core program.

>To each their own. But I suggest that all future sysops call and use BOTH
>systems, and give each system a good work out. I think (and hope) that you
>find ProLine slightly more to your liking.

However let them know exactly what is required.

>ProLine, by the way, can be run off an 800k disk. I did it.

LET ME KNOW HOW YOU DID IT!  I'm trying to get it to run off 2 800K disks
right now.  I'm currently trying to trace down access to each directory to
map them onto other drives.

>Matthew
>Email: sysadmin@pnet91.cts.com (most mailers won't barf on that..)

--
///   ____   \\\ "The major problem--one of the major problems, for there are
| |/ /    \ \| |       several--one of the many major problems with governing
 \\_|\____/|_//            people is of whom you get to do it, or more to the
greg \_\\\/ hoss.unl.edu    point, who gets people to let them do it to them."
