usenet@cps3xx.UUCP (Usenet file owner) (12/02/88)
-------------------------------------------------------------------------- [I have decided to post this as well as send it to 'chrisb' in the hope that it might spur some conversation.] -------------------------------------------------------------------------- Whew! This had to go a Loooong way to get to you! If it works, be sure to at least mail me to tell me that you got it. Anyway, you asked a question and I have a few answers that you might find interesting.... The Next Step in Bulletin Board Systems ------------------------------------------------ (In my humble opinion...) I really think that most if not all BBS soft that is popular these days suffers from a lack of change. If you sit back and look at it objectively, most BBSes support the same UserInterface/Options/etc. that the "Conference Tree" BBS supported in the late 70's. (Conference Tree, written in Forth and running on CP/M class machines was the first publically available BBS). If you look at the rest of our industry, you see incredible change and improvements. But not in the area of BBS communications! Why? Well, I believe that it has to do with the fact that most BBS sysops feel a necessity to support the "least common denominator" in terms of user, (i.e. the user who has only a DUMB terminal). Also a factor is the sysop's lack of programming ability. I have found that most sysops are not programmers or designers. They are mostly regular joes who are interested in the "communication" aspect of BBSes. It really saddens me to see what has NOT happened in the BBS community. So, for the last few years I have been exploring alternatives. What exactly is a BBS? At the very least, it must support the following features: Interuser mail. Multiple conferences. These are the aspects that, I believe, make it a "communications" medium. These areas are the most used features of BBSes, with the sole exception of "DOWNLOADING". I really believe that UL/DL features are the bane of BBSes. They take up massive amounts of time and space, and demand a large amount of the sysops time and energy to maintain. If I were designing a NEW BBS, (which I am, actually), I would not include any UL/DL capability except as an afterthought. My feeling is, there are far better machines out there that support UL/DL quite adequately, and I am certainly not going to attempt to compete with that. So, we are really left with mail and conferences, or are we? There are always "online games". Another boondoggle, I believe. What can an online game on a BBS offer that can really compete with the games that are currently avaliable on personal computers? Multiple players. And there again we have a serious "misuse of resources" problem. WHat is stopping your users from using your machine solely for games and nothing else? Nothing. Don't get me wrong! I like a really good computer game as much as the next hacker, but I think that the whole idea has to be re-thunk before we can offer really interesting options to our users. The Bottom Line ---------------------------------- I have an idea or three that I have been toying with for some time now, and am actually thinking about implementing. 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? 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 BBS could support, given the need, uploading and downloading, invisible to the user, and happening while the user was doing something else? Science Fiction? No. I think I have a model that would offer all this and more. There are two "catches". One: It really means that some fancy programming needs to be done. I am currently doing a little of it, and plan on doing more, but would like to get a group of people together to help design this. Two: The user would run special "terminal software" on their own machine. The first catch only means that it will take some time to realize this, while the second catch is a little more important. I am interested in your views as to whether or not the second catch is really THAT important. If the terminal soft were to be distributed free of charge to any interested parties, as well as the source, I think that there might be some interest. How is it done? -------------------------- Very similiar to the way in which the Internet operates. On a CLIENT/SERVER model of interaction. The BBS computer, (known as the SERVER), communicates with the users machine, (the CLIENT), through a simple communications protocol that is very similiar to Xmodem or Kermit. Something like the TCP/IP protocol, but much smaller. The only real difference to the forementioned protocols is the addition of a one byte "Channel Number". Channels are a method of creating multiple "virtual" communication channels over a single serial line. The idea looks a little like this: [MAIL SERVICE] [BULLETIN SERVICE] | | +----+ +-----+ (Where a Channel connects to | | a Service) --------------- SERVER --------------- | | | | | | | (Multiple channels) | | | | | | | ------------- Packet Driver ------------- | (Single REAL Serial Connection) | MODEM MODEM | | ------------- Packet Driver ------------- | | | | | | | (Back into Channels) | | | | | | | --------------- CLIENT --------------- | | +--------+ | |MAIL |---+ | | | | | | (Where a channel connects to a window) +--------+ | | CONF | +---------+ A packet knows what channel it is supposed to be in and thus ends up at either the proper window, (on the Client machine), or being sent to the proper service, (on the Server machine). The CLIENT runs the terminal software on his/her machine. The software dials the local SERVER and starts a session. The CLIENT requests that a mail service program run on channel one, a chat program run on channel two, and the conference program run on channel three. At the SERVER end of a channel, there is a program called a SERVICE, and at the CLIENT end of a channel is a window or a full screen, or some other fancy user interface. 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! If the Client supports graphics, we can have multi-user GRAPHICAL games where the client saves an "Object Library" locally on his disk. This Object Library is used to hold various small pictures, or icons, that are used in the game. In fact, each player could have his/her own icon that represents the player, and each player would get a copy of it to display on his/her screen. The image of a multi-user BBS game that uses pictures of each player as game pieces, I think, is rather unique! Well, I have rambled on quite a while now. If any of this is interesting to you, perhaps we could start a mail group to discuss these ideas. Regards, Rob P.S. If you have a quicker mail route to either uunet or mailrus, try sending your reply back that route. The way I had to get this to you was really rather absurd. ----------------------------------------------------------------------------- Robert Raisch - TechnoJunkie & UnixNut| UseNet: {uunet,mailrus}!frith!raisch Network Software Group-301 Comp.Center| InterNet: raisch@frith.egr.msu.edu Michigan State University, E. Lansing | ICBMNet: 084 28 50 W / 42 43 29 N ----------------------------------------------------------------------------- The meek WILL inherit the Earth, (Some of us have other plans). ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- Robert Raisch - TechnoJunkie & UnixNut| UseNet: {uunet,mailrus}!frith!raisch Network Software Group-301 Comp.Center| InterNet: raisch@frith.egr.msu.edu Michigan State University, E. Lansing | ICBMNet: 084 28 50 W / 42 43 29 N ----------------------------------------------------------------------------- The meek WILL inherit the Earth, (Some of us have other plans). -----------------------------------------------------------------------------
gl8f@bessel.acc.Virginia.EDU (Greg Lindahl) (12/02/88)
In article <1217@cps3xx.UUCP> raisch@frith.egr.msu.edu (Robert Raisch) writes: > >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? > > 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? > Sounds like a great idea! I had been thinking about this... and have a suggestion. There is a standard windowing interface, STDWIN, which is available from gatekeeper.dec.com via anonymous ftp. It currently has drivers for X11, the Mac, and Atari ST, and could no doubt easily have drivers done for MS Windows and PC GEM. It has a client/server module for TCP/IP, and with the addition of a serial packet driver, you could have a serial client/server setup. Interested? -- greg ---------- Greg Lindahl internet: gl8f@virginia.edu University of Virginia Department of Astronomy bitnet: gl8f@virginia.bitnet "grad students don't need disclaimers; the department doesn't care what I think"
srpenndo@uokmax.UUCP (Sean Richard Penndorf) (12/02/88)
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. 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. But are these types of things being held back in the BBS community? (Especially when it seems that the rest of the world has flown by us). The simple matter is money. Very few sysops have the capital to invest in a multi-node system to support things like conferences. Few sysops have the money to invest time and energy into creating a good graphics front end for their systems. And lastly, programmers of BBS Host programs are typically Shareware authors. Some of these authors are extremely gifted programmers but lack the team work and unity and capital of a software company like MicroSoft to create somthing brilliant simply because they don't have the resources. And naturally big software corporations are not going to invest in a BBS program because there is not a big market for it. Then you ask, "Why is Ultimatum Software working on one then?" Probably because we don't have everything together upstairs or something.... I don't know. Well enough of my "two half pennies". Hopefully with the post by Robert and myself, we can spark some constructive discussion here about the BBS software trends. The tide is turning, but ever so slowly. -- Sean 'Longstride' Penndorf !texsun!uokmax!srpenndo . . .----------- GEnie: S.PENNDORF | | `---. ---- The WEASEL Project ---- `--'LTIMATUM----'OFTWARE
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (12/03/88)
After running a number of BBS user agents, and spending two years
designing a new system, I'm also coding a BBS. Having spent all the time
I care to on design, I am not in any way soliciting any more input. I've
talked to a number of sysops and users, and done a VERY detailed design.
However, you are asking for input, so let me share a few general ideas
with you. First, if you are going multiuser, consider having a DOS
(single user) and UNIX (multiuser) version, rather than trying to get
DOS to support multiple sessions. It can be done, but DOS lacks the idea
of multitasking, file locking, validation, etc. This means that you get
to do that stuff yourself.
Consider the sysop first! Design the system so that it will take care of
itself to a reasonable degree. Again UNIX systems have a lot of tools to
do things like run backups and report generators at various times of
day, which can be done under DOS, but again without too much support
from the o/s. Be able to add and delete messages easily, and to take a
disk file which is not known to the BBS, and add it as a file or as a
message. The reverse is also desirable.
Consider if you want to have the sysop approve messages and/or files
before they are available to regular users. If you want this, make it
convenient. It really is a desirable feature, even if most people don't
use it.
When you delete files and messages, do you want to save them in a form
which allows reloading? If so you have to design your own backup and
restore format and programs, to save all of the header and description
info as well as the text, and of course some generation of a
description, preferably in a database, so you can reload. Sound hard to
do right? It is, but it will leave time for the sysop to do fun things
rather than routine stuff. After the first five years backups get REAL
boring.
Hint: if you want multi session under DOS there is a "communications"
region with some relatively portable calls to access it. THis might help
keep your ducks in a row.
User interface: at least three basic types, the type with all messages
in one big file, with consecutive message numbers, like CBBS; the type
with file and message areas each broken into groups, like RBBS and OPUS;
and the type with files attached to messages, broken into groups which
identify message and file topics, like Citadel and Magpie. Each of these
then has a threaded variant which allows chasing replies to a message.
This list is not complete, but you will have to make design decisions. A
good BBS will have several user agents.
Do you want to take advantage of neat graphics and color, windows and
other good stuff? Do you want to cut yourself off from the people with
the glass teletype, who may have lots of good ideas, even if they don't
have big bucks?
Storage of messages: one big file, one file per group, on message per
file? Take the easy way out and let the directory structure do most of
the work, or do it yourself for performance?
File protocols: what upload and download protocols do you want to
support? xmodem, ymodem, zmodem, kermit, window kermit, sealink, etc?
Build them in or run them a processes? Can you make several work at the
same time under DOS?
I have tried to give you some areas for thought rather than my decisions
on how to resolve these choices. I have spent a lot of time getting my
tools ready, including a table driven menu interface, a Btree database
manager, a screen interface, a table driven questionare interface, etc.
Each of these tools will be released by itself when I get the
documentation done. You will probably send a lot of time getting your
tools ready if you are going to "really do it right" as you intend.
Good luck.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mekarl@ddsw1.MCS.COM (Karl Denninger) (12/04/88)
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"
evan@telly.UUCP (Evan Leibovitch) (12/04/88)
In article <1217@cps3xx.UUCP>, usenet@cps3xx.UUCP (Usenet file owner) writes: > The Next Step in Bulletin Board Systems > ------------------------------------------------ > I really think that most if not all BBS soft that is popular these days > suffers from a lack of change. I beg to differ. The evolution of FidoNet, the creation of ever-more-efficient transfer protocols (Kemit, Ymodem), the emergence of multi-node and multi-user systems, and the development of ANSI-based graphic displays, all fly in the face of assertions that BBSs have been resistant to change. > If you sit back and look at it objectively, > most BBSes support the same UserInterface/Options/etc. that the "Conference > Tree" BBS supported in the late 70's. > If you look at the rest of our industry, you see incredible change and > improvements. But not in the area of BBS communications! Why? I have seen experiments in alternative user interfaces. They all died under real-world use. The good stuff stayed around. Call it the Darwinist theory of BBSs. :-) Besides, I think you are missing something important - that user interfaces are only one (and not even the largest, IMHO) of the facets of a BBS. Administration tools, security, inter-system communications, and other features are also important - and they have been improving steadily. > Well, I believe that it has to do with the fact that most BBS sysops > feel a necessity to support the "least common denominator" in terms of > user, (i.e. the user who has only a DUMB terminal). No, the least common denominator is someone who doesn't know what a dumb terminal is, and has been shown how to put in a communications disk, turn on a modem, and dial a number. > Also a factor is > the sysop's lack of programming ability. I have found that most sysops > are not programmers or designers. They are mostly regular joes who are > interested in the "communication" aspect of BBSes. And not all car drivers are mechanics, but that doesn't explain why cars don't last longer. I never fail to get irritated by programmers who think end-users should be programmers. For BBSs or anything else. Your 'regular joes' crack demonstrates a condescending attitude towards the poor souls that have to USE the software that programmers create. The skills necessary to administer a BBS, deal with abusive users, collect subscription fees, expire old files, keep bulletins current, get rid of virus programs, recover from power failures, check for libel, etc., are TOTALLY different from the skills needed to design and code software. It's arrogant to lay the blame on for 'BBS stagnation' on sysops who choose to concentrate on spreading information and running a secure maildrop, doing their best with the software that programmers make available. The best (and most successful) BBS systems I know of are are not run by programmers. > If I were designing a NEW BBS, > (which I am, actually), I would not include any UL/DL capability except > as an afterthought. Another example of programmers pushing their personal philosophies on end users. I can debate with you on the merits of uploading and downloading, but my main concern is that you would consciously make your software LESS useful. You recognize that UL/DL is popular, then go on to say it won't be an important part of your software because YOU don't think it's useful. > There are always "online games". Another boondoggle, I believe. What > can an online game on a BBS offer that can really compete with the games > that are currently avaliable on personal computers? Multiple players. > And there again we have a serious "misuse of resources" problem. WHat > is stopping your users from using your machine solely for games and > nothing else? Nothing. Has it occurred to you that some BBS sysops may WANT it that way? I agree with you that games are a waste of resources, but I would prefer BBS software which could reflect the sysop's vision of communications, not inflict the programmer's vision. > 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? Now THAT's a shopping list. Let's look at a few: Multitasking? Multi users? on an 8088? I wish you luck. You'd be best off not doing it from scratch, but using something like QNX. Windows; The UNIX 'curses' library allows 'C' programmers to make software using TERMINAL-INDEPENDENT pop-up windows. (Remember the lowest common denominator?) Icons; Forget it. Icons without mice is a useless exersize, and there are too many mouseless callers out there to make it standard. Games; The least you could do is to provide adequate hooks for the sysop to implement this if desired. Help; A great idea, but it's largely been done in the other good-quality packages. > 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. The ability to ask a user what kind of terminal he/she is using, and determine based on that what codes to use to clear the screen, etc. already exists on Unix and other multiuser systems. I would argue that the most serious constraint on BBS systems is DOS (ESPECIALLY if you want multiuser). > Science Fiction? No. I think I have a model that would offer all this > and more. There are two "catches". > > One: It really means that some fancy programming needs to be done. I > am currently doing a little of it, and plan on doing more, but would > like to get a group of people together to help design this. Perhaps a new GNU project? :-) > 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. It's a bit of a chicken-and-egg situation. If no callers will have it, sysops won't run the Server software. If no hosts support it, callers won't bother getting the Client program, regardless of cost. 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. > How is it done? > -------------------------- > The BBS computer, (known as the SERVER), communicates with the users > machine, (the CLIENT), through a simple communications protocol that is > very similiar to Xmodem or Kermit. Something like the TCP/IP protocol, > but much smaller. > > The only real difference to the forementioned protocols is the addition > of a one byte "Channel Number". Channels are a method of creating > multiple "virtual" communication channels over a single serial line. > 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. > 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, I have rambled on quite a while now. If any of this is > interesting to you, perhaps we could start a mail group to discuss these > ideas. Better still, let's keep it here in alt.bbs. The traffic isn't so big as to require moving this discussion elsewhere. I am interested in many of these ideas. As you may have noticed, I've disagreed with some premises and I think some of these 'features' aren't worth the energy. But that doesn't mean the discussion should lapse. It's obviously easier to be negative than positive, and I'll try to post some suggestions of my own in the future. For now, I'm just responding. > Regards, Rob -- Evan Leibovitch, SA of System Telly "I am most concerned that Located in beautiful Brampton, Ontario, Canada nobody will remember me evan@telly.on.ca -or- uunet!attcan!telly!evan when I am dead" - Anon.
gl8f@bessel.acc.Virginia.EDU (Greg Lindahl) (12/04/88)
In article <2324@ddsw1.MCS.COM> karl@ddsw1.MCS.COM(Karl Denninger) writes: [stuff deleted] > > 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. With a nice standardized package like STDWIN, the server program can be written in C and should function with few changes on all hardware. Also, most personal computers (pc klones, st, amiga, mac, ][gs) can easily handle this sort of stuff. > Then there is the speed issue. A graphics interface might be viable > on a 9600-baud modem. Nonsense. Think of what you do to read messages on a BBS. You alternate looking at windows which display messages, and windows which contain a reply or new message you're typing. Almost all of that can be handled by the server program... the host need only transfer the message or transfer back the new message. And message transfer for the next message can be done while you are reading the current message. Although you're doing a graphical interface, the BBS need not know that where the windows are or that the user is scrolling through it, especially for a message reading window. All it needs to know is when the window is closed or when the user picks a menu item, such as "Next Message" or "Reply". There isn't much more information transfer here than in a normal BBS. Now you would have to port STDWIN or whatever to all the machines involved. This is a problem on PC's -- there isn't any such thing as a run-time for GEM or MS Windows that you can distribute free with a public domain program, is there? But I think that the hardware technology exists already, and most of the software technology also. -- 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?"
tneff@dasys1.UUCP (Tom Neff) (12/05/88)
The last thing we need is yet another BBS. There are already too many of them out there. What we need is something more basic - a low level protocol on which anyone can define his/her OWN BBS. Everyone sets out to reinvent, not just the wheel, but the 1973 Camaro right down to the candy apple metal flake paint job. Who cares whether some software designer "hates" or "likes" downloading, or color, or glass TTYs, or whatever. That should be up to the hobbyist. A sophisticated client/server model (which, if I'm not mistaken, the original poster had backwards) would be a good start. Perhaps something can be built on one of the existing PD standards and adapted to several platforms. It would be nice, for instance, to be able to support full BBS functionality (however a site wishes to define it) over more than just voice grade dialed logins. -- Tom Neff UUCP: ...!cmcl2!phri!dasys1!tneff "None of your toys CIS: 76556,2536 MCI: TNEFF will function..." GEnie: TOMNEFF BIX: t.neff (no kidding)
jeff@lorrie.atmos.washington.edu (Jeff L. Bowden) (12/05/88)
All these ideas for user friendly BBS software are good.
BUT DON'T CASTE YOUR INTERFACE IN CONCRETE!
I think the best solution is to set up something similar to NNTP wherin the
caller asks the server for new message headers and messages. This solves two
problems:
(1) The server doesn't need to remember which messages each user has seen. The
user program handles this.
(2) Anyone with a computer can access it and no one is tied to a particular
interface which he may or may not like.
A simple line-oriented interface could be written in C and ported *everywhere*.
Fancier interfaces could be written for each machine by those who desire them.
It seems to me that much of the existing software that does netnews could be
adapted to implement this.
If you make your protocol public, *everyone* can get into the act.gl8f@bessel.acc.Virginia.EDU (Greg Lindahl) (12/05/88)
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?"
usenet@cps3xx.UUCP (Usenet file owner) (12/05/88)
in article <JEFF.88Dec4161711@lorrie.atmos.washington.edu>, jeff@lorrie.atmos.washington.edu (Jeff L. Bowden) says: > Xref: cps3xx alt.bbs:258 comp.misc:4402 > In-reply-to: gl8f@bessel.acc.Virginia.EDU's message of 4 Dec 88 07:44:05 GMT > > All these ideas for user friendly BBS software are good. > > BUT DON'T CASTE YOUR INTERFACE IN CONCRETE! > > I think the best solution is to set up something similar to NNTP wherin the EXACTLY!!!!!! ----------------------------------------------------------------------------- Robert Raisch - TechnoJunkie & UnixNut| UseNet: {uunet,mailrus}!frith!raisch Network Software Group-301 Comp.Center| InterNet: raisch@frith.egr.msu.edu Michigan State University, E. Lansing | ICBMNet: 084 28 50 W / 42 43 29 N ----------------------------------------------------------------------------- The meek WILL inherit the Earth, (Some of us have other plans). -----------------------------------------------------------------------------
desnoyer@Apple.COM (Peter Desnoyers) (12/06/88)
In article <2324@ddsw1.MCS.COM> karl@ddsw1.MCS.COM(Karl Denninger) writes: > >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. > Not true. I routinely use Applelink, which is a mail/bbs system provided by Geisco (?) to Apple, over an X.25 network with about 1200-2400 bps throughput during the day. The user interface is graphical, but communication isn't. You lose the advantages of integrated text/graphics (graphics has to go in upload/download files) but the system's implemented on some MIS-type mainframe that can't handle graphics, anyway. Peter Desnoyers
daveh@cbmvax.UUCP (Dave Haynie) (12/06/88)
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
donegan@stanton.TCC.COM (Steven P. Donegan) (12/06/88)
Tom, I think the point here is that we ARE re-inventing the wheel. Hopefully better and more flexible. Just because the concept of BBS environments is an everyday concept doesn't mean that it can't be made better. By the way, server -> client is the proper structure, not client -> server. After all, lots of Clients without a Server doesn't accomplish diddly( and a Server without Clients can exist quite happily thank-you). -- Steven P. Donegan These opinions are given on MY time, not Sr. Telecommunications Analyst Western Digital's Western Digital Corp. stanton!donegan || donegan@stanton.TCC.COM || donegan%stanton@tcc.com
evan@telly.UUCP (Evan Leibovitch) (12/06/88)
In article <2324@ddsw1.MCS.COM>, karl@ddsw1.MCS.COM (Karl Denninger) writes: > > [regarding availablility of good new conferencing software] > > 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 [...] > and you can purchase or scrape up from shareware/PD sources what you want > right now. What I don't understand is what everyone sees so wrong with Usenet news software, with which many of you are reading these very messages? It doesn't HAVE to be used for communications with other sites (though the added effort is minimal, once the news software's running). If one already makes the choice to go with Unix, what's wrong with using established software, which is freely available in source? Usenet news software, and associated Unix sources, make very good building blocks for a BBS. > 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....) Done in rnews, which is even more difficult on Usenet since submissions to a thread may come from many sources, and do not arrive synchronized according to when they were first posted. Granted, rn threads could use some work, and the program this is very cumbersome and hard-to-learn, but perhaps someone could rework this into something more manageable. Better than starting from scratch. > 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. Handled in Usenet newsreaders by maintaining a file for each user which contains "last read" info for each conference (.newsrc). > o An integral set of design decisions which permit and facilitate use of > the system in a linked environment (ie: share conferences w/neighbors). > [...] > 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. While Usenet B 2.11p14 has many warts, development on successors (Cnews, Bnews 3.0, and GNUs) has been far from stagnant, and even the old stuff accomplishes all of the above. > o Enough control 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. That's the beauty of Usenet. A common back-end and file format, combined with many different kinds of reading and posting front ends. You want an icon-based news reader? God bless. What it means is that the task of arranging and managing news (as opposed to reading, posting or downloading) is ALREADY THERE. > 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. What Usenet DOES lack is a front end for users which supports UL/DL protocols, however, source for both Kermit and X/Y/Zmodem is available in source. Shouldn't be to hard to build into a front end. > 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). So the front end takes control of the dial-in port rather than, say, 'getty'. Nothing special. User accounts are stored in a simple ISAM file which makes for quick response, and ISAMs are easy to come by. Still, I'm not sure what's so bad about using the Unix password file for user accounts if it's made bulletproof enough. A sloppy password can be broken no matter how it's stored. > 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. I personally have trouble with shell access to a BBS. Sounds too much like a deliberate Trojan Horse, just waiting to be exploited. But certainly if a BBS system stores a user's access level, that can be used to allow privileged users access to a shell. By using standard Usenet software, you can develop a tight front end for non-privileged users, while allowing your shell users access through conventional newsreaders. > 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. Check out Cnews expire. > 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. No question that this is desirable. > 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. You mean like the way I'm responding here, quoting you above while adding my own comments? Perhaps a split screen editor, which allows you to compose a message in one window while reading the original postings, would be a nice idea. But that is a part of the EDITOR, not necessarily the BBS program. > 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. To me, there is a distinct line between private mail and public discussions. Usenet combines the two well, and allows things like private responses to public postings. Again, a non-shell front end for 'captive' users would be desirable. > o Most things should be redefinable by the administrator; commands, most > prompts, options, and help screens/pages/entries. Absolutely vital. The question is - what skills will the admin need to make changes - text files, C code, shell scripts, etc.? > 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. And one, Usenet, which while not PD, is damned close to it, and the authors don't ask for money. > 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. I'm also designing a BBS, which is little more than a multiple-expert-level, menu/hot-key front end for existing Usenet software (and other commonly available Unix sources, like Kermit and Xmodem). It's no major piece of work, but it'll do what I think my users want. And it'll allow me to have NO shell access, except to admin people. Shell access to outside users still scares me. I find that Usenet software, properly configured and administered, makes for a very good conferencing system. It's not as straightforward as Karl's software (which, admittedly, I know only by his descriptions), and Usenet news readers can use some help (such as synchronizing threads). Still, I'm more concerned about not tampering with something that works already. And I have Usenet working... -- Evan Leibovitch, SA of System Telly "I am most concerned that Located in beautiful Brampton, Ontario, Canada nobody will remember me evan@telly.on.ca -or- uunet!attcan!telly!evan when I am dead" - Anon.
les@chinet.chi.il.us (Leslie Mikesell) (12/07/88)
In article <8083@dasys1.UUCP> tneff@dasys1.UUCP (Tom Neff) writes: >The last thing we need is yet another BBS. There are already too >many of them out there. What we need is something more basic - a >low level protocol on which anyone can define his/her OWN BBS. Absolutely! Now that PC's running terminal emulation probably outnumber real terminals it is time to get away from the "dumb" emulation modes and take advantage of the local CPU. If done in a reasonable way, it would allow host-controlled "fill-in-the-form" editing with the PC doing almost all the work, text editing with the PC doing all of the screen handling, etc. To make it work we need two standards: 1) a method of multiplexing data streams (X.PC?) and 2) a text based windowing system with the equivalent of "block transmit". This would allow the development of many programs (not just BBS's) that would run more efficiently. Les Mikesell
tneff@dasys1.UUCP (Tom Neff) (12/08/88)
In article <87@stanton.TCC.COM> donegan@stanton.TCC.COM (Steven P. Donegan) writes: >Tom, I think the point here is that we ARE re-inventing the wheel. Hopefully >better and more flexible. I heard this rationale in 1980, and I'm sure I'll be hearing it in 2000. After all, why do people bother to re-invent the wheel if not to make it "better." However, after 297 people have done this, you have to step back and ask whether (a) they really know about each other's wheels, (b) they really USE the wheels they have to the fullest potential rather than taking one quick look, saying "Ooooh, I don't like *that*" and whipping out the chisel, and finally (c) whether some broader kind of tool needs to be worked on instead. > By the way, >server -> client is the proper structure, not client -> server. After all, >lots of Clients without a Server doesn't accomplish diddly( and a Server >without Clients can exist quite happily thank-you). Actually (many servers) <-> (1 or more clients) is the right structure. The original posting characterized the BBS program as a "server" and the users who dialed into it as "clients." This can't be right in the modern "X" understanding of those terms. Each user's smart terminal software would comprise a display server, while the central BBS program would be a client (perhaps one of several) which would communicate with each users's display server via the appropriate network services (async, LAN or whatever). It would be possible to write something like this right now under X11, but the bitstream volume would probably be too high to support 2400bps logins. If you hauled the functionality higher, you could implement something universal that could run on lots of boxes, and quasi nationwide via the various nets as well as locally via dialup. -- Tom Neff UUCP: ...!cmcl2!phri!dasys1!tneff "None of your toys CIS: 76556,2536 MCI: TNEFF will function..." GEnie: TOMNEFF BIX: t.neff (no kidding)
karl@ddsw1.MCS.COM (Karl Denninger) (12/08/88)
In article <430@telly.UUCP> evan@telly.UUCP (Evan Leibovitch) writes: >In article <1217@cps3xx.UUCP>, usenet@cps3xx.UUCP (Usenet file owner) writes: > >> If you sit back and look at it objectively, >> most BBSes support the same UserInterface/Options/etc. that the "Conference >> Tree" BBS supported in the late 70's. > >> If you look at the rest of our industry, you see incredible change and >> improvements. But not in the area of BBS communications! Why? > >I have seen experiments in alternative user interfaces. They all died under >real-world use. The good stuff stayed around. Call it the Darwinist theory >of BBSs. :-) This I have to agree with 100%. We've tried several different things; people come back to what they know and like. The cutesy interfaces and whiz-bang graphics terminal setups have been tried already; they DIED from a lack of users. Why? Because they were artificially limiting their audience. (There are a few notable exceptions; Quantum Link is one example... but they ALL cater only to one type of machine and/or software) >Besides, I think you are missing something important - that user interfaces >are only one (and not even the largest, IMHO) of the facets of a BBS. >Administration tools, security, inter-system communications, and other >features are also important - and they have been improving steadily. EXACTLY. A few years ago I had an interlinked system running on Model III machines (Tandy). This before Fidonet had even "bow wow'd" it's first bark. It was a horrible kludge, but darn it, it moved mail and bbs files back and forth across the country for quite some time. One set of sites in Texas is STILL using the email part of it in a network of about a dozen systems -- on Tandy Model IVs. We've learned a whole heck of a lot since then; our current offering's security, easy of administration and flexibility massivly outclass the old ERACS systems -- but then again, we're not on a 64K Z80 based system anymore either! >> Well, I believe that it has to do with the fact that most BBS sysops >> feel a necessity to support the "least common denominator" in terms of >> user, (i.e. the user who has only a DUMB terminal). > >No, the least common denominator is someone who doesn't know what a dumb >terminal is, and has been shown how to put in a communications disk, turn >on a modem, and dial a number. Or the person who has a real terminal -- as in a mainframe user who can dial out, but does NOT have ANY... ANY.... ANY... WAY to get local intelligence. DUMB terminals (as in "glass tty") are all but gone; we can safely ignore these.... Or can we? Ignoring glass ttys, my friends, means ignoring more than half the Commodore owners -- or about 60% of the PC's out in the PERSONAL computer world today! What was it you said about PC's being only $400? With a modem, and DOS, and.... yeah, keep dreaming. A minimal PC needs help -- enough memory to work (ie: 256K), floppy and modem, display, monitor, keyboard.... getting the idea yet? You're looking at a $500-600 machine; more if you don't go with a "no-name clone"! Heck, a C64 + disk + modem can be had for $200-300! Which one can Mr. Auto Worker afford more easily, and which of the two do his KIDS want? Not the IBM with monochrome screen! >> Also a factor is >> the sysop's lack of programming ability. I have found that most sysops >> are not programmers or designers. They are mostly regular joes who are >> interested in the "communication" aspect of BBSes. > >And not all car drivers are mechanics, but that doesn't explain why cars >don't last longer. I never fail to get irritated by programmers who think >end-users should be programmers. For BBSs or anything else. > >Your 'regular joes' crack demonstrates a condescending attitude towards >the poor souls that have to USE the software that programmers create. Yep; it's our position that anyone who can turn on the power, log in as root, and read a manual should be able to handle running the system. If you can't do all that you call us -- after 10 minutes you can indeed! (assuming you can read, of course :-) If that doesn't work, WE SCREWED UP (or any other BBS system author/publisher). >The best (and most successful) BBS systems I know of are are not run >by programmers. I'd debate that (and I'm very biased) ;-) >> If I were designing a NEW BBS, >> (which I am, actually), I would not include any UL/DL capability except >> as an afterthought. > >Another example of programmers pushing their personal philosophies on end >users. I can debate with you on the merits of uploading and downloading, >but my main concern is that you would consciously make your software LESS >useful. You recognize that UL/DL is popular, then go on to say it won't be an >important part of your software because YOU don't think it's useful. Agreed; why should you force anyone in either direction? The best solution is to provide a smoothly-integrated and carefully designed method for having it either way -- you can have downloads, or you can do without them; the administrator gets to choose. There are a lot of sites that don't want d/l capability that are using AKCS -- they simply don't enable the option. But for the sysadmin who DOES want to have the areas available, the capability is there, built in, and not a "hacked in" afterthought that will cause a lot of grief. >> There are always "online games". Another boondoggle, I believe. What >> can an online game on a BBS offer that can really compete with the games >> that are currently avaliable on personal computers? Multiple players. >> And there again we have a serious "misuse of resources" problem. WHat >> is stopping your users from using your machine solely for games and >> nothing else? Nothing. > >Has it occurred to you that some BBS sysops may WANT it that way? > >I agree with you that games are a waste of resources, but I would prefer >BBS software which could reflect the sysop's vision of communications, not >inflict the programmer's vision. Boondoggle? Waste of resources? I'm sorry, but I have to disagree here. We have a very nice multiplayer space game; it's not terribly piggish with machine resources, it works, and it's a ton of fun -- better than simply taking on a computer ANY DAY; there's a human element involved. I'd never run software that prevented me from making a choice to offer such a game on the system -- that's way too restrictive! In fact, I need capability to interface (or at least "gate" to) ANYTHING. On a Unix machine, it's perfectly reasonable for a person to execute commands within a restricted environment. >> 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? > >Now THAT's a shopping list. Let's look at a few: > >Multitasking? Multi users? on an 8088? I wish you luck. >You'd be best off not doing it from scratch, but using something like QNX. Yes, or making the "minimum platform" an AT and run Microport or SCO... >Windows; The UNIX 'curses' library allows 'C' programmers to make software > using TERMINAL-INDEPENDENT pop-up windows. (Remember the lowest > common denominator?) This is the way to go if you must have windows. I'd hope you'll stay reasonable; believe me, there is nothing that slows down a perfectly good application faster than trying to run in a windowed environment; ask anyone who is _skilled_. The first-timers ooh and aaawww over it; when it comes down to brass tacks, the cutesy stuff LOSES. Why? Almost without exception: the time savings for new users are minimal, while the time LOST for the experienced user is not trivial or necessary. >Icons; Forget it. Icons without mice is a useless exersize, and there > are too many mouseless callers out there to make it standard. Agreed (once again, C=64, VT100 terminal, any mainframe user). >Games; The least you could do is to provide adequate hooks for the sysop > to implement this if desired. Absolutely a requirement. >Help; A great idea, but it's largely been done in the other good-quality > packages. Also absolutely a requirement, and it has to be definable by the sysadmin. >> 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. Painfully slow is being too nice :-) >The ability to ask a user what kind of terminal he/she is using, and >determine based on that what codes to use to clear the screen, etc. already >exists on Unix and other multiuser systems. I would argue that the most >serious constraint on BBS systems is DOS (ESPECIALLY if you want multiuser). You bet. We thought long and hard about this before deciding to go with Unix rather than DOS as a base for AKCS; DOS was just too restrictive in what it would support, and offered nothing but more work for us in implementing what we wanted to do. >> 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. > >It's a bit of a chicken-and-egg situation. If no callers will have it, sysops >won't run the Server software. If no hosts support it, callers won't bother >getting the Client program, regardless of cost. > >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. You've also gotta figure on another problem. Disregarding those who just CANT run the client (and that is a LOT of people, folks!) leaves you with lots of systems to support -- at a minimum you need Amiga, Atari, C=64, and IBM (DOS & OS/2, 2 versions!). Oops -- you just excluded all the 3b1/7300's, all the Tandy gear (there's a LOT of it!), all the SCO Xenix machines, and all the....... Getting the idea yet? This is going to be one HELL of a lot of work, yet without the client software no one will use the thing! >> 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. Yep; and those files are HUGE!!!! Ever look at the size of an HP font file? Or a bit-mapped screen image (or any significant piece of it?) 5-10k comes to mind as a reasonable number for some icons... how long did you say you were willing to wait for that transfer of the 300 D&D monster icons for that neato game? The only scheme that I see as being practical at all is very, very simple server with a highly-complex client piece for each system. This also allows you to build a "text only" interface that can run locally (given Unix as a base system). This comes with it's own set of problems -- now you've got security headaches up the wazoo to deal with as well! -- 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"
mlewis@unocss.UUCP (Marcus S. Lewis) (12/08/88)
> > > >Multitasking? Multi users? on an 8088? I wish you luck. OK, I get real tired of this. Disclaimers: I own a Heathkit H/z100 (non PC-DOS MS-dos) machine. I don't like the whole culture that has grown up around the PC, since I remember when a PC was not made by IBM. I have seen an 8088 running 16 users accessing databases with full screen control. Let's not put down the 8088, there's nothing wrong with it that prevents its use as a multi-user machine. MS-DOS, now is a problem. For a counter-example, see the Tandy Color Computer, a 0.9 MHz 6809 running OS/9, multi-tasking, color graphics, etc. For a hell of a lot less then the cost of a PC clone. This machine I have seen running as a 3-user developmert machine, so let's not put down a wimp CPU for the wrong reasons. Marc Lewis
ads4@tank.uchicago.edu (adam david sah) (12/08/88)
The problem is that you are assuming that everybody wantys UNIX. Ture, you and I would just LOVE UNIX, but let's face it- UNIX and the whole usenet news system is about the most user hostile system anyone's ever seen! Don't even think for a minute that Unix/Rn, etc are friendly enough "for the average person"There aren't even any menu support, any oftentimes no online help. Unix is computer software written by professionals for professionals... If you don't believe me, try using something like searchlight bbs- there are a hundred ways to do everything, and online help is just a "?" or an "F1" away... -A.Sah'88 SysOp, The Art of Science BBs 312-752-6104
karl@ddsw1.MCS.COM (Karl Denninger) (12/09/88)
In article <437@telly.UUCP> evan@telly.UUCP (Evan Leibovitch) writes: +In article <2324@ddsw1.MCS.COM>, karl@ddsw1.MCS.COM (Karl Denninger) writes: +> +> [regarding availablility of good new conferencing software] +> 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 [...] +> and you can purchase or scrape up from shareware/PD sources what you want +> right now. + +What I don't understand is what everyone sees so wrong with Usenet news +software, with which many of you are reading these very messages? It doesn't +HAVE to be used for communications with other sites (though the added effort +is minimal, once the news software's running). Lots of things are wrong with the Usenet software. While I'm very much in the various author's debt for this code we all know, love, and use, it's really a quite-horrid mess. Ever try explaining Usenet, how to use the various readers, reply to mail, edit a newsgroups line, on and on ad-nauseum to a rank computer beginner? +> 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....) + +Done in rnews, which is even more difficult on Usenet since submissions to a +thread may come from many sources, and do not arrive synchronized according +to when they were first posted. Rn has a _horrible_ means for doing this. In addition, since the net software itself doesn't respect any kind of threading, we have these enormous quoting problems.... in some cases, half of our traffic on a given day begins with ">"! +> o Enough control 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. + +That's the beauty of Usenet. A common back-end and file format, combined with +many different kinds of reading and posting front ends. + +You want an icon-based news reader? God bless. What it means is that the +task of arranging and managing news (as opposed to reading, posting or +downloading) is ALREADY THERE. The front-ends we have now, quite frankly, are crippled due to the internal structure that Usenet uses. 'rn' is a mess and does all kinds of wierd things to perform it's tricks (and has a hack or two in the news software itself just for it's use :-) Yes, it does work, but me gawed is it kludgy, and more importantly, a pain in the neck for the administrator! +> 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. + +What Usenet DOES lack is a front end for users which supports UL/DL protocols, +however, source for both Kermit and X/Y/Zmodem is available in source. +Shouldn't be to hard to build into a front end. There's a problem with this; you have to be _real smart_ when your pieces come in 50K at a time, and you have to get all <x> pieces before you have something useful. At least the net has a standard binary format (uuencode), but what in the devil do you do with shar archives of source? Transferring the postings raw to the end user is worse -- now the USER has ot understand not only how to read and access the net, but the bits and pieces needed to put back together these articles. Easy for us, difficult for the average Joe who knows how to insert a floppy in his drive and boot the PC (or type ATDTxxxxx to a terminal). +> 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). + +So the front end takes control of the dial-in port rather than, say, 'getty'. +Nothing special. User accounts are stored in a simple ISAM file which makes +for quick response, and ISAMs are easy to come by. + +Still, I'm not sure what's so bad about using the Unix password file for +user accounts if it's made bulletproof enough. A sloppy password can be +broken no matter how it's stored. Not the point; Unix shell accounts have other problems which have to be dealt with, including disk resources and a limited namespace (some passwd files barf at 32K; Microport SV/AT is a good example!) THAT particular problem with Microport makes a large system (500+ users) on a '286 IMPOSSIBLE without some external help. +> 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. + +I personally have trouble with shell access to a BBS. Sounds too much like a +deliberate Trojan Horse, just waiting to be exploited. But certainly if a +BBS system stores a user's access level, that can be used to allow privileged +users access to a shell. If the user came from the shell, he should be able to access the shell. You've already granted him/her access to it in the first place. For non-shell users (captive accounts) you can't (and shouldn't) be able to get out. +> 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. + +No question that this is desirable. Not desirable -- more like required. Reading an entire man page looking for a command's description doesn't cut it anymore. +> 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. + +You mean like the way I'm responding here, quoting you above while adding +my own comments? + +Perhaps a split screen editor, which allows you to compose a message in one +window while reading the original postings, would be a nice idea. But that +is a part of the EDITOR, not necessarily the BBS program. Ok, so now go back (while EDITING) and reference the ORIGINAL POSTING that started this thread. IMPOSSIBLE with the current scheme of things! Incorporating an editor (but not _THE_ editor) into the package makes it a LOT faster; have you ever waited 30+ seconds for vi to start up on a slow machine? You don't wait like that when there isn't an extra "fork()/exec()" to do in the meantime.... +> 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. + +To me, there is a distinct line between private mail and public discussions. +Usenet combines the two well, and allows things like private responses to +public postings. Again, a non-shell front end for 'captive' users would be +desirable. Yes, and in this regard the net does do a reasonable job; email is handled without too much hassle. +> o Most things should be redefinable by the administrator; commands, most +> prompts, options, and help screens/pages/entries. + +Absolutely vital. The question is - what skills will the admin need to make +changes - text files, C code, shell scripts, etc.? An admin shouldn't have to be more than proficient in an editor and reading (for the manual) to be able to configure things. It is absolutely unacceptable to expect a user to know how to program in order to be able to set up the system to fit their needs! +> 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. + +And one, Usenet, which while not PD, is damned close to it, and the authors +don't ask for money. And is designed for a completely different audience than the typical "bbs" user; the "pucker factor" for a new Usenet user is quite large. For a computer professional this is easy; for a neophyte who just bought his/her system at the local Radio Shack this is a VERY important issue! -- 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"
jzitt@dasys1.UUCP (Joe Zitt) (12/09/88)
In article <8083@dasys1.UUCP> tneff@dasys1.UUCP (Tom Neff) writes: >The last thing we need is yet another BBS. There are already too >many of them out there. What we need is something more basic - a >low level protocol on which anyone can define his/her OWN BBS. Note that the MAGPIE developers are working on creating a user-redefinable command set. Any user would be able to completely design his/her own interface to the system using a fairly simple command development language. -- {sun!hoptoad,cmcl2!phri}!dasys1!jzitt Joe Zitt Big Electric Cat Public Access Unix also: uunet!wwd!joe (WorldWide Data) The worldlines of the needle and the digit intersect -- Paul Pedersen, 1988
sewilco@datapg.MN.ORG (Scot E Wilcoxon) (12/09/88)
In article <7095@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <8083@dasys1.UUCP> tneff@dasys1.UUCP (Tom Neff) writes: >>The last thing we need is yet another BBS. There are already too >>many of them out there. What we need is something more basic - a >>low level protocol on which anyone can define his/her OWN BBS. TCP/IP allows programs on one computer to talk to programs on another computer. Radio amateurs have been using PCs to run TCP/IP for a while (um.. KA9Q?). TCP/IP can run over a serial line via SLIP. Low level protocols exist. >... > 1) a method of multiplexing data streams (X.PC?) > and > 2) a text based windowing system with the equivalent of "block transmit". 1) Yes, please allow multiplexing data. For example, it would be nice to have an article index and file transmissions to go in one direction while email and file requests are flowing in the other direction. 2) Yes, sort of. A windowing system should not be part of the data transfer definition. The data transfer system should work with any data, as TCP/IP can. Windowing might be done by programs running on one or both machines which are using the data flow, but any windows should be dependent on the programs being used. `inews` doesn't care what the screen of `rn` or `vnews` looks. Then there's NNTP...for news over a network. And any text-only standards should be discouraged, especially when we're talking about using many machines which already have graphics hardware. -- Scot E. Wilcoxon sewilco@DataPg.MN.ORG {amdahl|hpda}!bungia!datapg!sewilco Data Progress UNIX masts & rigging +1 612-825-2607 uunet!datapg!sewilco I'm just reversing entropy while waiting for the Big Crunch.
pab@naucse.UUCP (Paul Balyoz) (12/09/88)
From article <8140@dasys1.UUCP>, by tneff@dasys1.UUCP (Tom Neff): > In article <87@stanton.TCC.COM> donegan (Steven P. Donegan) writes: >> By the way, >>server -> client is the proper structure, not client -> server. After all, >>lots of Clients without a Server doesn't accomplish diddly( and a Server >>without Clients can exist quite happily thank-you). > > Actually (many servers) <-> (1 or more clients) is the right > structure. The original posting characterized the BBS program as a > "server" and the users who dialed into it as "clients." This can't be > right in the modern "X" understanding of those terms. Each user's > smart terminal software would comprise a display server, while the > central BBS program would be a client (perhaps one of several) which > would communicate with each users's display server via the appropriate > network services (async, LAN or whatever). > -- > Tom Neff UUCP: ...!cmcl2!phri!dasys1!tneff The client/server idea really is the way to go. But the question is how far do you want to go when implementing it? Let's look at what could be done, given unlimited time and resources. There exists a server process on a computer, which is being the "host" of the BBS, to which it's users dial in and connect to. We are assuming multitasking, multi user ability, multiple modems and phone lines, because a single process host with a single modem and phone line is a subset of this more complex system. Design this bigger version, and the same ideas will work for the smaller hosts, such as personal computers. The Server centralizes all BBS concepts, such as real-time conversations between users ("chat" or "CB radio") and system messages (Sysop broadcasts a message to all users), as well as stores and maintains all data-bases for the message-base, electronic mail, downloading, news, etc. The Client is a "front-end" to the server, converting the information from a cryptic but compact, well-documented BBS protocol (which goes across the modem connection) into a more user-friendly display (possibly including graphics, if the client knows what to draw when). Thus the transferred codes may look remotely like: T74 causing the client to interpret this as it knows how, displaying the message: "There are 7 letters in your mail box, 4 of which are unread. Someone paged you earlier, but you weren't around." (Maybe the "T" stands for True: someone paged you earlier.) Now, because the transmission consisted of three ascii characters instead of the two-line text stream in English, we've achieved an *impressive* transmission speed far beyond that of generic BBSes of today. The assumption of course, is that all users have a version of this client software running on their particular system. But what can we do for people dialing in with dumb terminals? Or with small micros which best emulate a dumb terminal? There should be client software available in runnable form on the host machine, not just the server. Then the scenario would be like this: Dumb Terminal <==modem==> client process <--> server process \____ _____/ \________________ ________________/ \/ \/ user's terminal host computer Now our host is doing a little more work for this user than a present-day BBS, but it is acting just like one. The English text strings now have to be sent over the modem resulting in the same slow-down as other BBSes, but we have the distinct advantage of being ABLE to serve those with the special client software. In other words, the user is given yet another incentive to upgrade from his dumb terminal to something better: a pronounced improvement in his telecommunicating. And if an average host running this server and client system has, say, half of its users using our BBS's client software and half not, then we have already achieved a definite improvement in speed over the old-style BB systems. How do we get the client software out to the population? Easy. One of the downloading sections of our BBS just happens to contain the client executable code for various computers that users might have. The host notes when this user isn't using any client software yet, and asks him about his system. Is it a dumb-terminal? If so, then it bears with them, letting them use the BBS from that perspective. If they really have a computer running some kind of terminal-emulation software, then are they interested in a vast improvement with a refined, user-friendly interface? If so, allow them to download the client software appropriate for them. Next time they call back, they will probably be using that client program! As additional encouragement to use the client software, they can be told about areas that are only accessable via client software interface: graphic games, artwork, background downloads, etc., which are not implemented in text-only form. And the latest client software will always be available from the host, because it came with the server software to begin with! The interface for the server <-> client interface must be well-defined, clear, and well documented. More importantly, it should be public domain! (What would things be like if _readnews_ was our only news reader?!?) Security issues are simple. Don't leave choices up to the client software - the ultimate yes/no control over the BBS is left to the server's decision. This way, when people implement their own clients, they can't say "broadcast to everyone on the system," "read that other users mail," or anything else -- unless the server allows them to. This way nobody can write a client which can disrupt the BBS. Some of the more advanced implementations can include multiple hosts connected via a LAN, each one having a server, for a HUGE BB system, should the owner of such a system wish to bring one up! This high-end version would still fit in with the above description, as there would only be one "virtual server," because each physical server would trade any and all info with all other physical servers. "Gee, download THAT file? Lets see, it's not on my hard disks; oh yea, server #7 over there has it. Hey server #7, can you send this file to me over the LAN? Thanks..." And the download begins. -------- I sincerely apologize for the length of this document! I've been thinking about these ideas for a long time, ever since I implemented a bulletin board system of my own design on a local Honeywell mainframe a few years ago. (8000 lines of Fortran, and not too interesting; but gave me many ideas!) What do you guys think? Is it do-able in under 100,000 lines of C? What would be the minimum size host that you'd need to support a system as large as this? (Hopefully a honed-down version would even function on Apple II/TRS-80/IBM-PC type machines). I will take all flames with reasonable humor, as all this is still only in the design stage.... "when can we start?"-edly yours, -- paul -- -- Paul Balyoz uucp: {ucbvax!allegra,ihnp4}!arizona!naucse!pab P.O. Box 1972 Flagstaff, AZ 86002 --
ok@quintus.uucp (Richard A. O'Keefe) (12/09/88)
In article <1089@tank.uchicago.edu> ads4@tank.uchicago.edu (adam david sah) writes: >The problem is that you are assuming that everybody wantys UNIX. Ture, >you and I would just LOVE UNIX, but let's face it- UNIX and the whole >usenet news system is about the most user hostile system anyone's ever >seen! Well, now we know that (adam david sah) hasn't used MVS+TSO or VM/CMS or pre-rev-19 PR1MOS or ... Which is not to say that UNIX is perfect. AT&T had a UNIX PC which did have icons & such standard on it. Whatever happened to that box (7300)?
michael@taniwha.UUCP (Michael Hamel) (12/10/88)
In article <1089@tank.uchicago.edu> ads4@tank.uchicago.edu (adam david sah) writes: >Don't even think for a minute that Unix/Rn, etc are friendly enough > "for the average person"There aren't even any menu support, any > oftentimes no online help. Yeah. >If you don't believe me, try using something like searchlight bbs- > there are a hundred ways to do everything, and online help is just > a "?" or an "F1" away... Yeah, thats really awful. How confusing. I mean, the average person just naturally thinks of the "F1" key when they don't know what to do, don't they. And hundreds of ways to do everything has to be good because... well.. theres just so much of it and more of anything has to be better. .... I apologise for the above outburst, but we Mac users lose control occasionally, especially when we have been forced to use "vi" for eight weeks... -- "Pay no attention to this swine," I said to the hitchhiker... Michael Hamel | currently ..!{unisoft|mtxinu}!taniwha!michael University of Otago | soon to be ..!ucbvax!michael@otago.ac.nz
thad@cup.portal.com (Thad P Floryan) (12/10/88)
Richard O'Keefe asks about AT&T's UNIXPC ... They're still around; very active in comp.sys.att and the unix-pc.* newsgroups. Some 70,000 of the UNIXPC (aka 3B1 aka 7300) were mfd, and at the "closeout" sale price of 1987-1988 they're one heckuva bargain; I have 4! :-) Quick overview: 10MHz 68010, MMU, (demand?) paging, variety of HDs, 3-button mouse, expansion slots, 512K to 2MB RAM on motherboard, some variant of SVR2 with a lot of extensions, hires tilt'n'swivel monitor (monochrome), keyboard "garage", sh & ksh, GNU stuff runs fine, etc. Nice system for under $2,000. A number of Amiga developers have UNIXPCs as adjuncts. Thad Floryan [thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad]
peter@ficc.uu.net (Peter da Silva) (12/11/88)
Just so long as it runs over SL/IP... -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: I accept full responsibility for my typos. peter@ficc.uu.net
rbrewer@reed.UUCP (Robert S. Brewer) (12/11/88)
In article <243@taniwha.UUCP> michael@taniwha.UUCP (Michael Hamel) writes: >In article <1089@tank.uchicago.edu> ads4@tank.uchicago.edu (adam david sah) writes: [Lots of text about Searchlight BBS deleted] >[...] And hundreds of ways to do everything has to be good >because... well.. theres just so much of it and more of anything has >to be better. > >I apologise for the above outburst, but we Mac users lose control >occasionally, especially when we have been forced to use "vi" for >eight weeks... That's an awfully weird thing to say for a Mac user (don't worry, I am too :-). One of the main features of the Mac interface is that there is more than one way to do things. Quick example : to eject a disk, you can select it from the menu, type command-E, or drag the disk into the trash. What were you trying to say? -- Robert S. Brewer Bitnet: rbrewer@reed.BITNET, Usenet: rbrewer@reed.UUCP Freshman, Reed College GEnie : R.BREWER
fargo@pawl17.pawl.rpi.edu (Ethan M. Young) (12/13/88)
As to the subject of supporting glass TTY's and ASCII terminals:
Instead of being stuck supporting ONLY ASCII dumb terminals, nor instead of
relying heavily on specialized protocols, a good BBS should allow the user to
choose which system he/she wants depending on the user's terminal set-up. If
the user is stuck with a measly Courier terminal, then give that user the sup-
port available for a Courier. But, if the user just happens to have a 2000x
2000x24 bit color display running a terminal emulator to handle it, then you
shouldn't have to stick that guy with a Courier interface. All this can be
made as simple as selecting a menu item, hitting a letter, etc. which says,
"Which terminal emulator can you support? (C)ourier (V)T-100 (A)NSI etc."
Thank you and happy hunting! Internet: fargo@pawl.rpi.edu ____ [> SB <] fargo@{paraguay|uruguay}.acm.rpi.edo
/__ -=>??<=- Bitnet (??): usergac0@rpitsmts.bitnet
/ ARGO : 3000 years of regression from the year 4990hassell@tramp.Colorado.EDU (Christopher Hassell) (12/13/88)
In article <2070@imagine.PAWL.RPI.EDU> fargo@pawl17.pawl.rpi.edu (Ethan M. Young) writes: >As to the subject of supporting glass TTY's and ASCII terminals: > >Instead of being stuck supporting ONLY ASCII dumb terminals, nor instead of >relying heavily on specialized protocols, a good BBS should allow the user to >choose which system he/she wants depending on the user's terminal set-up. If ^^^^^^ >"Which terminal emulator can you support? (C)ourier (V)T-100 (A)NSI etc." > >Thank you and happy hunting! Internet: fargo@pawl.rpi.edu ____ [> SB <] fargo@{paraguay|uruguay}.acm.rpi.edo > /__ -=>??<=- Bitnet (??): usergac0@rpitsmts.bitnet > / ARGO : 3000 years of regression from the year 4990 One last time, No one out there Dare to allow ONLY non-graphic client-progs under pain of being foolish :-b. The idea should be, as was said, to have a lowest-default or simple recognition system for the DUMB among us (terminals that are) and the smart too, of course. a concerned vt100, (ttyia)@tramp.Colorado.EDU Disclaimer: The current user has no responsibility for the text in this article. He's off eating right now probably. (geezmyspacebaraches). (gets crumbs between keys too, the dope)
srpenndo@uokmax.UUCP (Sean Richard Penndorf) (12/15/88)
In article <2070@imagine.PAWL.RPI.EDU> fargo@pawl17.pawl.rpi.edu (Ethan M. Young) writes:
=>As to the subject of supporting glass TTY's and ASCII terminals:
=>
=>Instead of being stuck supporting ONLY ASCII dumb terminals, nor instead of
=>relying heavily on specialized protocols, a good BBS should allow the user to
=>choose which system he/she wants depending on the user's terminal set-up. If
=>the user is stuck with a measly Courier terminal, then give that user the sup-
=>port available for a Courier. But, if the user just happens to have a 2000x
=>2000x24 bit color display running a terminal emulator to handle it, then you
=>shouldn't have to stick that guy with a Courier interface. All this can be
=>made as simple as selecting a menu item, hitting a letter, etc. which says,
=>"Which terminal emulator can you support? (C)ourier (V)T-100 (A)NSI etc."
=>
This is what I have been saying all along. Allow the user to choose what type
of interface his computer and software will support. Since the general
consensus here seems to be bent on communication, it would seem logical to
support as many possible configurations as possible. However, while still
supporting the old (ancient, dinosaur, or whatever other metaphors) ASCII
TTY dumb terminal, new BBS programs SHOULD move forward and try to
incorporate a graphics protocol.
The best way to move forward in the graphics scene is to come up with a
standard for all computers and software to follow. This standard will have
to be Public Domain so that it reaches as many software developers as possible.
Without a standard then we will be limiting everyone and which BBS's they can
call. Until a good general standard is designed, graphic BBS's will be small
in number and will be limited in what machines it will support. So, until a
graphics protocol standard is designed that is as generic as TTY (or perhaps
VT-100), and implemented on all computers, BBS host programs should
continue to support ASCII TTY.
--
Sean 'Longstride' Penndorf
!texsun!uokmax!srpenndo . . .-----------
GEnie: S.PENNDORF | | `---.
---- The WEASEL Project ---- `--'LTIMATUM----'OFTWARE