On Thu, 22 Feb 2018 12:56:11 -0500, Seymore4Head 
declaimed the following:


>How hard would it be for BBS software to run on telnet?
>
 Would depend upon how the BBS software "answers" in coming calls.

 In the time of the ancients, BBS software was connected to banks of
modems (each having a phone line), and (hypothetical -- I've not looked at
any such code) had pending threads (or a coroutine design) for each modem
waiting for a login attempt; after which it would process the connection
until a logoff or time-out, whereupon it would return to the pending
connection state.

 Concurrency would be limited to the number of modems. Each modem
handler would loop: wait for login attempt; validate login; loop processing
commands; return to top of outer loop on logout or timeout [probably long
timeout to allow for slow human interaction, or some disconnect signal from
the modem].

 Conversion to Telnet/SSH basically means the "wait for login attempt"
is a TCP/IP "accept" operation. After that, anything that can map TCP
socket I/O to the equivalent of a serial modem stream should allow the rest
of the code to remain unchanged.

 I don't know if the AX.25 (Amateur Radio variant of X.25 Packet) is
applicable -- in the 90s one still found AX.25 packet servers with
email/BBS features. These days, AX.25 packet data seems to be relegated
mostly to APRS (which is more UDP [unconnected broadcast] than TCP
[point-to-point connection] style)


>I remember years ago that I had some program that would do telnet and
>there were BBSs you could connect to.  Could BBS software be modified
>to be accessed from the web using a browser link?
>
 It would be tedious -- since the main idea behind HTTP is that EACH
data transfer is independent and complete. Hence the need for either
Cookies (which identify which transaction this transfer is associated with,
and what stage that transaction is in) OR AJAX (running a Javascript
program in the user's browser which is talking to a server and updating the
browser "DOM" -- IE; writing a BBS client in Javascript that uses the
browser to update the main browser window in place of loading new pages for
every update).

 Telnet/SSH/Serial would be all text based system, and might be
dependent upon the client capability (can it handle ANSI escape sequences
to clear screen, move cursor... etc.) but should be functional on a minimal
system (remember printing terminals? -- a screen update would be scrolling
a full screen of data, but still doable). A BBS specific client might be
smart enough to buffer entire messages, and allow the user to scroll back
and forth locally without having the server resend lines. The smartest
clients would act similar to NNTP clients -- downloading all new messages
to local storage, allowing the user to read/respond to those message while
not connected, and then send all responses on the next connection {This is
how the Aladdin clients for GEnie functioned -- since one was billed by
connection time, no one wanted to read the messages while connected --
connect, spend 5 minutes transferring pending data, disconnect... Spend an
hour reading/responding.}


>I also always wondered how hard it would be to get programs to run
>from the cloud instead of being housed on a personal machine.
>
 UGH! this means one need a permanent connection, and one is basically
acting on a per-message basis -- every change of message means hitting the
server machine and transferring a packet.
--
 Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

--- SoupGate-Win32 v1.05