In the year 2000, my (telnet + MCP & MCCP & other acronyms-supporting) C-based MUD boasted a _web_ interface.
With colors, buttons to move, and even _images_.
A web request is just a TCP socket, and browsers were gracious enough to start displaying stuff as soon as it came in (so long as tags were properly closed). So long as you sent stuff fairly routinely, the connection wouldn't be closed.
Frames helped... well, "frame" the interface: main frame would be the mud's output; another frame for user input - both using a shared "key" to ensure output and input were linked to the same user.
Users' input could therefore easily just be sent on another web request, checked for key correspondance, and the command ran as if the user input the same command via telnet: action -> response.
A sprinkle of that new-fangled JavaScript helped ensure the screen would scroll properly as soon as new output came by.
Having previously abstracted all color-related stuff (to ensure strings like "&WFoo&GBar&X" would send ANSI colours to users opting-in to them, and nothing to users opting out of them) meant that it was "easy" to send "<span color='white'>Foo</span><span color='green'>Bar</span>" to the HTML interface instead.
Websockets? We don't need no stinkin' websockets! _really long_ polling suffices ;)
With colors, buttons to move, and even _images_.
A web request is just a TCP socket, and browsers were gracious enough to start displaying stuff as soon as it came in (so long as tags were properly closed). So long as you sent stuff fairly routinely, the connection wouldn't be closed.
Frames helped... well, "frame" the interface: main frame would be the mud's output; another frame for user input - both using a shared "key" to ensure output and input were linked to the same user.
Users' input could therefore easily just be sent on another web request, checked for key correspondance, and the command ran as if the user input the same command via telnet: action -> response.
A sprinkle of that new-fangled JavaScript helped ensure the screen would scroll properly as soon as new output came by.
Having previously abstracted all color-related stuff (to ensure strings like "&WFoo&GBar&X" would send ANSI colours to users opting-in to them, and nothing to users opting out of them) meant that it was "easy" to send "<span color='white'>Foo</span><span color='green'>Bar</span>" to the HTML interface instead.
Websockets? We don't need no stinkin' websockets! _really long_ polling suffices ;)