Xref: utzoo alt.bbs:265 comp.misc:4289 Path: utzoo!hoptoad!amdcad!ames!xanth!mcnc!uvaarpa!hudson!bessel.acc.Virginia.EDU!gl8f From: gl8f@bessel.acc.Virginia.EDU (Greg Lindahl) Newsgroups: alt.bbs,comp.misc Subject: Re: New Ideas in BBSes (No BS!) Keywords: BBS Client Server Network Message-ID: <849@hudson.acc.virginia.edu> Date: 5 Dec 88 01:54:08 GMT References: <1217@cps3xx.UUCP> <430@telly.UUCP> Sender: news@hudson.acc.virginia.edu Reply-To: gl8f@Virginia.EDU (Greg Lindahl) Distribution: na Organization: Dept. of Astronomy, University of Virginia Lines: 137 In article <430@telly.UUCP> evan@telly.UUCP (Evan Leibovitch) writes: >In article <1217@cps3xx.UUCP>, usenet@cps3xx.UUCP (Usenet file owner) writes: > >> The Next Step in Bulletin Board Systems >> ------------------------------------------------ [ stuff deleted. i only want to comment on a few things here... apologies in advance for quoting out of context. ] >Windows; The UNIX 'curses' library allows 'C' programmers to make software > using TERMINAL-INDEPENDENT pop-up windows. (Remember the lowest > common denominator?) This is slow if you do it in the normal Unix fashion. Too many things to transmit. >Icons; Forget it. Icons without mice is a useless exersize, and there > are too many mouseless callers out there to make it standard. Actually, I think the whole point of this exercise (to me) is to extend BBSes to deal with graphics and mice -- your milage may vary. I'm a bit biased, but I don't think you're going to see a revolutionary advance without additional requirements. You can easily purchase mice and windowing for a PC klone; the Amiga, ST, Mac and //gs come with them. >> 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 would probably be the most significant leap, allowing users to compose >messages with full-screen editors, use arrow keys to make selections, and >use colour when available. Just remember that most terminal emulator programs >of most computers, even the ones with high-quality graphics, cannot take >advantage of bit-mapped images. Those that do, like software that emulates >Tectronic 4014 terminals, draw images painfully slow at 2400bps. Tektronix graphics are vector-oriented, and an 8088 might easily be CPU bound on displaying them at 2400 baud. Bitmaps would also be very slow. However, should the abstraction be done on a higher level: menus, windows, etc. then it could be fast. > [...] I would argue that the most >serious constraint on BBS systems is DOS [...] What's that? Oh, you mean MS-DOS and PC-DOS. I thought for a minute that you were refering to DOS, the Disk Operating System for IBM 360's back in prehistory. [...] >> Two: The user would run special "terminal software" on their own >> machine. > >Big problem. It would have to be written totally differently for each system >planning to dial in, to take advantage of all the graphics features you want. >Writing this program, and the GETTING CALLERS TO USE IT, will be a far tougher >chore than writing the host BBS software itself. Take an interface like STDWIN, or your favorite high-level windowing interface. Port it to all the machines involved. Write a GENERIC client program in C. Amazing, it's mostly the same everywhere! Getting the callers to use it will be difficult... But if the bbs is revolutionary enough, they would. Hopefully. >If you can't get your Client software to support older systems like Fido, >BIX and Compu$erve as well as existing packages like Procomm and Qmodem, >the whole idea of non-standard Client software is dead in the water. Translation: the client needs a VT100 window and support for the old file-transfer capabilities. >> How is it done? [...] > >You've REALLY gotta concern yourself whather the benefits from this will >be worth the huge programming headaches you have in store (not to mention >the extra admin headaches ahead for sysops who use this). Computers may >be multitasking, but most users have problems with even a single task at >a time. I myself see no need for 'virtual' channels over a single line. >Especially if you intend to run this on an 8088. Let's see, the first channel passes graphics events. The second transmits messages. The third handles downloads/uploads. So while the user is reading the current message, the next one is already being transmitted. When that's all caught up, the upload/download files flow, ALL WHILE THE USER IS READING MESSAGES! Think of all the time you sit there reading while your modem rests. Most people read more slowly than 1200 baud. So the faster that modems get, the more time they spend sitting idle. At the same time, we can hide file-transfer protocols from the user, by having some sort of negotiation system. Protocols are a programmer-level concept; probably many users would prefer to not have to deal with them. Of course, we still have to have good performance in all kinds of environments. >> If the Client supports graphics, we can have multi-user GRAPHICAL games >> where the client saves an "Object Library" locally on his disk. > >Are these downloaded, or is the Client expected to have them? If it's >downloaded, than the Server must have multiple copies of all graphics >and icons for each type of supported hardware. Well, in the STDWIN case (and I would suggest that we need to start coming up with specific models here), the "graphics" would be either menus or sets of drawing commands, all of which are machine-independent. Icons are resolution dependent, but I don't like to use them anyway, other than icons built into all servers. Once again, apologies for showing quotes out of context. Please refer to the referenced article for full quotes :-) I am aware of 2 different efforts to do BBS programs of this type. One is a Mac-specific effort to get Quickdraw graphics to run in a client/server fashion. This would be totally Mac specific unless you want to try to duplicate quickdraw (good luck), and is on an awfully low level, so it will require a LOT of information exchange and will be slower than a higher-level interface. I forget where I saw info about this; somewhere on a Mac BBS or something. The other is just a terminal program which would cooperate with the underlying BBS system. Once again I forget where I saw this. The idea is simple: have the user do graphical operations and the terminal program generates the appropriate fake keystrokes. I think this was going to be for PC klones and would work with Fido. Of course, this kind of stuff has been around before; I do a little of this by typing replies in my full-screen-edit capture buffer and uploading them into a bbs' line-editor. I hope I've provided some food for thought. -- greg ---------- Greg Lindahl internet: gl8f@virginia.edu University of Virginia Department of Astronomy bitnet: gl8f@virginia.bitnet "When a 300' dish falls in the woods, and nobody hears, does it make a sound?"