Following a discussion on TMC, it was pointed out that MSDP doesn't explicitly state that it's out-of-band, or that the data should be in a separate data stream from the text. It does mention "out of bounds", which I always assumed was intended to mean the same thing, but it's not explicitly stated.
This is kind of important because my snippet does treat it as a separate data stream - after receiving data from the client it parses all of the MSDP data first, and then parses the regular text, as if the MSDP data were "urgent data". Equally, at no point does it rely on MSDP data being sent in a specific sequence with the text - it assumes the MSDP data is independent of the text.
Tyche brought to my attention the fact that in ZMP "Commands must be sent in-order with other commands and the regular MUD data stream", much like MXP, or ANSI colour codes. I also recall IRE trying to do the same with its Comm.Channel package, which raised the point that you can't actually do that in MUSHclient because "It basically treats the stream as two distinct, multiplexed data streams, and deals with one before the other. No context is shared between them".
MSDP doesn't seem to have any such reliance on the text stream, but neither does it explicitly rule it out, so as it grows in popularity it may be that sooner or later someone tries to interleave MSDP data with the text stream. Am I correct in assuming that this is not allowed?
Thanks for the clarification. If someone specifically chooses not follow the specification then that's their call, I'm just trying to avoid arguments over the wording and intent.
Definitions provide clarity, and this is especially important since the term "out-of-band" has a different meaning on the TCP/Telnet transport layer that MSDP actually runs on. The MCP 2.1 Specification has a similar requirement to MSDP and uses the same terminology. However, they define its usage so there is no confusion.
This is kind of important because my snippet does treat it as a separate data stream - after receiving data from the client it parses all of the MSDP data first, and then parses the regular text, as if the MSDP data were "urgent data". Equally, at no point does it rely on MSDP data being sent in a specific sequence with the text - it assumes the MSDP data is independent of the text.
Tyche brought to my attention the fact that in ZMP "Commands must be sent in-order with other commands and the regular MUD data stream", much like MXP, or ANSI colour codes. I also recall IRE trying to do the same with its Comm.Channel package, which raised the point that you can't actually do that in MUSHclient because "It basically treats the stream as two distinct, multiplexed data streams, and deals with one before the other. No context is shared between them".
MSDP doesn't seem to have any such reliance on the text stream, but neither does it explicitly rule it out, so as it grows in popularity it may be that sooner or later someone tries to interleave MSDP data with the text stream. Am I correct in assuming that this is not allowed?