Xref: utzoo alt.bbs:249 comp.misc:4230 Path: utzoo!hoptoad!amdcad!ames!mailrus!eecae!cps3xx!usenet From: usenet@cps3xx.UUCP (Usenet file owner) Newsgroups: alt.bbs,comp.misc Subject: New Ideas in BBSes (No BS!) Keywords: BBS Client Server Network Message-ID: <1217@cps3xx.UUCP> Date: 1 Dec 88 18:42:47 GMT Reply-To: raisch@frith.egr.msu.edu (Robert Raisch) Distribution: na Organization: Michigan State University, Engineering, E. Lansing Lines: 212 -------------------------------------------------------------------------- [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). -----------------------------------------------------------------------------