Does it really make sense?
I mean people who still wants to use ATARI as a BBS server - they probably prefer real hardware against a PC software like RespeQt.
They would use "Black Box" and Lantronix, etc.
Otherwise you may run BBS software on a PC (it doesn't matter for clients connecting via Telnet) and you don't need ATARI and RespeQt.
I'll let the guys who run BBSes decide that.
Anyway we may start with a Telnet Client support only and add Server support later.
That said, yes, it's no problem to leave it out for the moment and only add it later.
And what about multiple clients?
The way you usually program a threaded socket server is: call accept() in a loop; spawn a new thread to handle the new connection.
For the "ATARI - RespeQt" approach we would handle only one client at a time?
Yes, you could either accept only one connection at a time or you can continue to accept connections, and just send some sort of 'busy' message.
This is a good idea. I realized that Altirra configuration requires first to add a 850 device emulation and then to add a modem emulation.
And that said, Altirra probably provides a decent model for how to do this. It's probably a safe bet that if you don't quite know how to implement something, it can be implemented similar to how altirra behaves. Differences will arise, of course, between an SIO device emulator and a full machine emulator as far as the lower level details go.
Shall we use the original R: Handler from 850? Or maybe the Altirra version?
Since the "concurrent i/o" mode shall be left as soon as the command line is raised, we would either break support for "NONE" and "SOFTWARE" handshake or we would need a protocol layer in a R: Handler and in RespeQt which would allow us to send a message to force leaving "concurrent i/o" mode. I will do it this way in a SIO2BT app, so a similar approach can be implemented in RespeQt.
Any R: handler should be OK to use, it's not really important as long as they provide the same functionality. And yes, support for NONE and SOFTWARE handshake will be difficult in an 850 styled device. There are ways to do software protocol though, like you said, that can effectively signal the emulated 850 to exit concurrent mode without hardware handshaking. Personally, I would pick an unlikely character, such as 0x00, to be a special character. Consider this character to be a sort of 'control code introducer.' You then follow it with a second byte which indicates what the emulated R: device should actually do.
So, for example:
0x00 0x00 - literal character 0x00 should be sent by R:
0x00 0x01 - drop out of concurrent mode
0x00 0xnn - various other codes for doing useful things without dropping out of concurrent mode (maybe changing handshaking mode, for example, other R: commands etc.)
The Atari has to scan the data going out for 0x00 and replace it properly. This is why I chose 0x00, because it is particularly easy to detect on the 6502, just load the value and check the zero flag. This is only a good idea if 0x00 is an infrequent character to be sent, which is probably a safe assumption to make. Otherwise it results in potentially a large performance penalty, sending two bytes for one byte of information.