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