Xref: utzoo comp.misc:4279 alt.bbs:259 Path: utzoo!hoptoad!amdcad!apple!bloom-beacon!mit-eddie!rutgers!mcdchg!ddsw1!karl From: karl@ddsw1.MCS.COM (Karl Denninger) Newsgroups: comp.misc,alt.bbs Subject: Re: New Ideas in BBSes (No BS!) Summary: What you want exists and works, you just need a _REASONABLE_ base Keywords: BBS Client Server Network NOMSDOS Message-ID: <2324@ddsw1.MCS.COM> Date: 3 Dec 88 19:53:31 GMT References: <1217@cps3xx.UUCP> <2093@uokmax.UUCP> Reply-To: karl@ddsw1.MCS.COM(Karl Denninger) Followup-To: alt.bbs,comp.misc Distribution: na Organization: Macro Computer Solutions, Inc., Mundelein, IL Lines: 144 In article <2093@uokmax.UUCP> srpenndo@uokmax.UUCP (Sean Richard Penndorf) writes: > >You raise some very interesting viewpoints there, Robert. > >We at Ultimatum Software of Oklahoma are working towards some of those goals >you just mentioned. The problem of the graphics interface in BBS's before >was the lack of computers which REALLY supported good graphics. That is >obviously changing very rapidly (ie, Macs, IBM PS/02s, Amigas, Atari STs, etc). >The second problem to the graphics front end is the speed. Unless you can >some up with a very FAST system for the graphics, I feel most users will >fall back to the standard ASCII type BBS. Yep. Then there's the kicker -- many people don't have systems that can handle it, even today, and those that DO will require a specialized client software package -- one for EACH type or brand of system you support. Who's going to do the work to create/port these monsters? This is not a jab -- it's a serious question. If you work with graphics-capable hardware you know that everyone does it a little differently; some do it a LOT differently. There is NO standard at the moment. What you are speaking of is on the order of re-creating X-windows specifically for this task (ie: simpler perhaps, but still a formidible programming job!) Then there is the speed issue. A graphics interface might be viable on a 9600-baud modem. Unfortunately, even today those are $500 and up; out of reach for the mainstream. 2400 baud is reasonable, you can find those mail-order for around $100 if you're willing to put up with horrid quality. In reality most of our callers are at 1200 or 2400. A few have an HST and come in at 9600, a few (mainly Unix sites) come on using the Telebit. In the next 2-3 years, we'll probably see $500 V.32 modems; 9600 baud full duplex. We might even see a $400 Telebit. But 2400 baud modems will be only $50-100 at that point -- which will the general public buy? Excluding 50% or more of your potential users is not a good move. >ANother interesting feature you mention is multiple- conferencing. Writing good conferencing software will entail some very creative thought. >Especially when you add the term "multiple" to it, meaning that more than >one conference can take place at one time. Try AKCS or Picospan for starters. Fully threaded, with multiple conferences (how much disk space do you have for the messages?). >But are these types of things being held back in the BBS community? Nope. You just have to look in the right places. You start by taking your head out of the MSDOS world; like it or not, DOS just wasn't meant to support multiuser operation OR multitasking. Yes, it can do both -- but not well. Start with a base of Unix or Xenix (which means only an AT-class machine with a couple of meg of RAM is required at the minimum) instead of MSDOS, and you can purchase or scrape up from shareware/PD sources what you want right now. >The tide is turning, but ever so slowly. The tide IS turning, and not slowly at all! My list of "must haves" for a "real" conferencing system: o Threaded messages, so I can figure out what the #$@% is being said and follow the thoughts. (The admin has to be able to move things around with reasonable facility, too....) o As many conferences as the person has disk space for, and an easy way for users to select which conferences they wish to view. Users should be able to leave a conference for a few days or weeks and then return without seeing everything again; the system must maintain the 'has seen' information. o An integral set of design decisions which permit and facilitate use of the system in a linked environment (ie: share conferences w/neighbors). I've seen several "hacks" [Fidonet anyone?] (and admit to writing one for Tandy machines a long time ago); while those work they are far from "good". What's needed is a system which is efficient, doesn't allow "loops" to occur, and gets the responses and items to all connected sites. To meet all of those goals you must be reasonable about how you connect sites to the network AND the software must have been designed to handle the linkage from the outset. o Enough information must be kept around so people only have to look at what is new; this implies variable-length summary files of some kind. Users also should be able to tell the system to disregard a given topic of discussion (ie: forgetting an item exists). o Enough control for the user so the information is presented the way the user wants to see it (within reason). Part of this is based on system layout; multiple threaded menus that you must traverse are _maddening_ for experienced users and not that much help for novices. o Attached file areas, so you can use it as a UL/DL area (with quotas and "smart" protocol support). Users should be able to attach files to replies and responses as well (as in "here's patch kit 3 for xxxx"). The system has to be able to manage these files, and enforce download quotas. o A secure captive user system so the host OS doesn't have to have 500 user accounts defined (along with the problems that develop from that). The standard items such as time limits should be enforced. At the same time people with "shell" accounts must not be hindered in using the software; 'fer instance, a shell user should be able to "shell escape" from a conferencing session, while a captive user obviously must not be allowed to do this. o A means to graft available job-scheduling software in the OS onto the conferencing software. I don't want to be FORCED to expire old items at 30 days, for example, nor do I want a limited set of options. But the tools must be there to do what is needed from timed-execution scripts (ie: crontabs on a UNIX system), or provide the entire timed-execution environment if the host OS can't handle it. o Keyword-based help available nearly anywhere (ie: at "yes/no" prompts is a bit overkill, but it ought to work everywhere else). The source files should be system-admin redefinable. o Context-sensitive editors available so people can see prior responses and postings while composing mail and reply messages -- preferrably in the same format as the user asked for while reading it in the first place. For non-captive users, a nice touch is the ability to use external editors of the user's choice. o A flexible external-package attachment system which is capable of preserving the security of the system for captive users (allowing you to graft on a 'C' or other language program to the conferencing system). o User-selectable personalities (within system-manager definitions) are desirable; people like what they know, and being able to emulate some of the characteristics of their favorite environment is always a plus. o Methods to reply by and handle mail within the conferencing software are also nice (although not _necessary_ within the framework of an open discussion). Once again, this has to work across different machines. o Most things should be redefinable by the administrator; commands, most prompts, options, and help screens/pages/entries. There's several packages out there which can do most of this; some are shareware, some are commercial, you might even find a PD one. I can't claim to be unbiased; we produce conferencing software for Unix and Xenix systems. I've tried to keep this from turning into an ad; a good chunk of it is what we've had suggested to us. Flames to /dev/null. Questions and constructive comments to the mail address below or call voice; people who want to check out conferencing first-hand can call the DATA number in the .sig (or vpnet, or igloo, or chinet, or any one of many other sites). The system below is PC-Persuitable (ILCHI). -- Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl) Data: [+1 312 566-8912], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality solutions at a fair price"