BS>> (A danish pop band did actually made a song there is
 BS>> named Dr. Jones, are you a Ph.D? ;))

 BJ> No, or not yet.....

 BS> Are you studying?

I need to get working on getting a teaching certificate.....  I haven't
investigated the options yet.  Probably would end up being a Master's in
Education, but who knows.  I already have a master's in software
engineering, but that hasn't helped in the market over the past two
years.....  I'm too odd ball for some of the folks in this area, and
areospace business is still depressed......

 BJ>> Based on how the telnet code is currently working (for as far as
 BJ>> Wes has progressed the code to date), the WFC screen is needed.

 BS>> Unfortionally it's.. Made because Wes, do only emulate
 BS>> the modem, by implementing the write/get calls to the
 BS>> modem.

 BJ> Basically true.  But it is done that way because that is how Max is
 BJ> coded for hooking into right now.....

 BS> Okay, I didn't look so mutch in the WFC source, so I 
 BS> know how things works..

 BS> Actually I did more concentrate on Squish..

Understand.....  And we've got a working Squish.  This is what I expected,
squish would become stable and (fully) functional before Maximus would
reach the same level of (its) usability.

 BJ>> The
 BJ>> telnet code is only a single line support right now, and is like
 BJ>> running a barefoot maximus or opus under DOS or
 BJ>> OS/2 (or Windows).  To
 BJ>> get to the point of multi-line, the telnet stuff will need to be
 BJ>> changed.

 BS>> Automatically it's multiline. (It's here..)

 BJ> And how are you handling multiple telnet sessions at one time?

 BJ> (a)  Are you Starting each up on a different tcp/ip port?

 BS> No on the same.. It can just take more users.

Ok.  Then I must have been hiting the timing bugs in my testing and gave up
too soon.  I have yet to succeed in getting two telnet sessions to max
running on the single startup....

 BJ> (b)  Are you running a copy of Maximus for each telnet session?

 BS> No.. It starts automatically with the runbbs.sh script?

The runbbs.sh script I thought only started up one copy of Maximus, with
only one sysop console, and I thought would only allow one telnet
connection in.  Now if a second concurrent telnet connection is being
allowed, I am gessing that the second sysop console is going to the bit
bucket, or the sysop console is going to look very interesting.....

 BJ>> To prove that you only have a single line BBS support, try
 BJ>> to make 2 or more telnet sessions to the same maximus telnet port
 BJ>> at one time.  Only the first will succeed.....  And if you bring
 BJ>> up a second copy of max/Linux for handling a second telnet port,
 BJ>> you will have to use a different TCP/IP port number.

 BS>> Well yes it handles only one telnet port, but more than
 BS>> one can be logging into the system at one time!

Ok.  I have yet to see that work on my linux system.....

 BJ> How are you starting maximus for this?  I don't think I've seen that
 BJ> work.  How are the BBS sysop consoles handled in this siutation?

 BS> I'm using the script which is included in the contrib 
 BS> dir afair.. Here is it:

Ok.  I think I was using the stock runbbs.sh for starting the telnet at one
point.  At a later point the telnet stuff went bust, and I haven't applied
your (old library) fix for that yet.  It's also possible that I made my own
runbbs.sh or modified it based on my understanding of things, or that I'm
running an older copy of it.....

 BS> === Cut ===
 BS> #! /bin/sh
 BS> #
 BS> # $Id: runbbs.sh,v 1.3 2003/07/05 00:13:51 wesgarland Exp $
 BS> #
 BS> # $Log: runbbs.sh,v $
 BS> # Revision 1.3  2003/07/05 00:13:51  wesgarland
 BS> # Fixed bugs processing echomail/netmail, etc
 BS> #
 BS> # Revision 1.1  2003/06/12 02:09:56  wesgarland
 BS> # Initial Revision
 BS> #
 ...
 BS> === Cut ===

I may be running an older version....  Hmmmm.....  Yup, I'm running version
1.1.  I wonder why that wasn't updated.....  Hmmmm.....  Interesting.... 
CVS is getting the new runbbs.sh script in my source tree, but 'make
install' is not installing it.....  I'll have to look into this.  This (and
possibly other files not getting copied on 'make install') is probably why
the telnet code broke for me.....  And maybe why I'm looking some echo /
netmail....  Hmmmm..

 BS>> Well why don't write a natively TCP/IP connection module?

 BJ> This is where the maxpipe and other issues may 
 BS> come in.  I believe the
 BJ> (current) design of maximus includes a sysop console per available
 BJ> connection....

 BS> Hmm.. Afaik is the sysop login just starting up like 
 BS> another maximus process?

Depends on how you start it up.  I've been using 'bin/max -k' to log in on
the sysop console.  In that case, I am comming in differently then telnet
or serial port / modem connections, but is running another copy of maximus
as it's own process.  This is like how I run a sysop login under OS/2 and
leave my BBS up on the other nodes.  When running under regular DOS (with
out any multi-tasker), you had to take the BBS down to log in on the sysop
console (again with the -k option).

 BS> Or is the sysop console the WFC screen?

The 'sysop console', from my view, is one per maximus session.  So each
potential maximus session (telnet connection or dial-in modem / serial
port) needs it's own sysop console, at least that's how it is under Win32
and OS/2 (and DOS running a multi-tasker like Desqview).  The WFC screen is
what the sysop console screen sees waiting for someone to connect.  Once
connected, the sysop console can (usually, the way I have it configured)
shows what the usesr sees.  Now with telnet support, you can have two
command windows open, one running maximus (with the sysop console up) and
the other running telnet connected to the BBS.  When you have both windows
up (able to be done under X), you see the duplication between the two
windows.  Hmmm....  Maybe that's part of my problem...  I'm running under X
instead of the 4 (or more) virtual system consoles you get when not running
X windows.

 BS>> [IPC]

 BJ> All user interactions are displayed on their screen and on the sysop
 BJ> console for that session.  So, the basic IO package is configured for
 BJ> this.....

 ... 
 BS>> Why actually using VMODEM? Why not native TELNET?

 BJ> Because maximus (under DOS, Win32 and OS/2) does not support native
 BJ> telnet.

 BS> But it could (easyly?) be ported, for win32.. I'm not scure about OS/2..

It should port back to both Win32 and OS/2 platforms that have TCP/IP support. 

 BS> Well Wes is modulizing the communication module, so on 
 BS> DOS you only compiles the "POTS" module..

Which is reasonable.  That will leave compatibility for recompiling the
code for DOS, Win32 and OS/2 and allow them to run as they currently do (if
someone gets that development environment working) and would allow us to
take the telnet code back to Win32 and OS/2 if someone can help on those
platforms....

 BJ> It support only what it thinks is a modem for the user.  Max
 BJ> was designed to control a modem off a serial port interface, with a
 BJ> sysop console on the system console....

 BS> Hmm..

 BJ> To do anything else is a
 BJ> major code change....  Which is also why Wes did the telnet support
 BJ> the way he did (for now)......

 BS> Yes..

Take care.....

Bob Jones, 1:343/41



--- Maximus/2 3.01