> > I've been toying with the idea of a nicer interface lately, as many of us > have. Ideally, I'd like something that wasn't line-buffered, so you > could send and receive individual characters. I'm not sure how feasible > this is, though. read() and write() seem to read entire lines only, and > telnet does the same. Does anybody know if there's an equivalent of > noncanonical input mode for telnet connections? > Not true. Telnet has a char-by-char mode that can be selected at startup or from within the application. read() and write() have no concept of a "line" they simply (attempt to) put/get the number of bytes specified. No distinction is made between regular alpha characters and controls (newlines, returns etc.) The other gentleman makes a valid point that char-by-char mode increases network overhead, though it isn't quite as bad as he paints the picture. It would seem that the best solution is indeed to write a client, but even then char-by-char mode is unneccessary. If it's a smart client, all of the command line editing can be handled locally and special characters or packets can be sent to the mud for command line completion and such. This brings up an interesting point --- the smarter the client is, the less packet traffic is required. i.e. if the client knows a good deal about the mud, it can do a lot of the work that the mud does now. This is not without risk. If the client knows a lot about the mud, then it can be hacked and that information used to the players advantage. This was a common problem when I used to write netrek code. You wouldn't believe the hoops we used to jump through to verify that the user was using a clean client. The other problem with a client is that it forces your users to get (and keep the most current version of) the client, something lots of mudders may be unwilling to do. Well, enough babbling... the whole point is that making a useful client involves more than you might think... and a simpler client turns out to be a fancy text editor, perhaps not worth the trouble. -Todd
This archive was generated by hypermail 2b30 : 12/07/00 PST