|
The problem is that 'fully parsed' is a non-trivial state to spot, especially given that the parsing has to be done on the same level as all the telnet and ANSI parsing. When I spot a '<' character in a mode that allows MXP tags, I need to enter a 'might be an MXP tag' state, start buffering text, and can only emit that text once I have parsed a complete tag, which is non-trivial.
The line modes aren't the issue here.
It's ok saying MUD's 'should' use those entitles, but it's quite clear from several MXP examples on the spec page that they don't have to - look at the 'start' and 'end' entity examples - and that open and closed brackets take on different meaning depending on their position, which makes parsing harder. Unfortunately this also no means that no complying client can assume that such brackets will be sent as entities. That's an issue with MXP. This means I can't just search for a closing bracket to terminate a tag, as I could in well-formed XML, hence the 'non-trivial' comment above.
And this means that if someone sends a prompt in open or secure mode like: "<hp 50 mv 150]" then your client has to make a guess as to whether that's an MXP tag that you have to wait to parse (as there is still a bit missing), or normal data to output to the MUD. Yes, while in your 'might be MXP' state you can keep checking the buffer and spot that 'hp' isn't a valid tag, but then do you emit the text, or do you report an invalid tag? And what if the user set part of a valid MXP tag in their prompt?
In fact, the whole protocol is a complete mess. Unclosed tags get closed at the end of the line... unless they were sent in secure mode... and who knows whether you close them or not when open mode is locked across multiple lines since one sentence suggests you do and one suggests you don't. It's almost a joke.
|