These are chat archives for Mudlet/Mudlet/whatever
Just looking under the stone that is Telnet option negotiation 🤢 and spotted that GMCP (ATCP, and 102) is(are) applicable in BOTH directions but it is not obvious that we actually negotiate it like that - e.g. we set
enableGMCP as soon as we get either a DO or a WILL and do not negotiate BOTH directions as we ought as I understand it at the start HE (as SERVER) sends us a WILL to which WE (as CLIENT) reply DO and then enable the use of the option from HIM to US, however it is not obvious to me that WE (as SERVER) also sends a WILL separately to await HIM (as CLIENT) to replay with a DO/DONT in order for us to enable using the option from US to HIM... my head aches getting this clear in my mind 🤕
Also spotted KazDragon's Telnet library on GitHub which seems to be an active, up to date implimentation if we should ever decided to use a pre-packaged TelNet class.
cTelnetclass with a pair of six-state
enums to track each pair of options (HIM->US and US->HIM)...
DONTfor all suboptions it doesn't know about
DONTfor an option you do not understand is the correct response however this is mitigated by the user/a script registering an interest in the option with a Lua call to
addSupportedTelnetOption(optionNumber)that sets a flag in
(QMap<int, bool>) cTelnet::supportedTelnetOptionswhich changes that to a
DO- mind you that only works for communications from HIM to US - it is down to the user/script to manage any negotiation for US to HIM (we send WILL option and await a DO back) - and I am not sure our code responds to that correctly as we then send another WILL in response to things that we understand...
however this is mitigated by the user/a script registering an interest in the option with a Lua call to addSupportedTelnetOption(optionNumber)
That's what I mean: I am not sure that telnet library is able to do that.
I have asked a question on SE lets see if I get any biters...
I think it does, the README points out:
activate()- this is used to request activation on the remote side.
set_activatable()- this is used to allow the option to be activated from the remote side.
on_state_changed- this is a signal that is called when the option is either being activated, active, being deactivated, or has become inactive.
WILLto request HE uses the option to SEND TO us
DOfrom HIM so we use option to SEND TO him
addSupportedTelnetOption(including callback to raise an event...)