Subject: Re: Lisp apps, threading, & debugging From: Erik Naggum <erik@naggum.net> Date: Fri, 22 Feb 2002 11:24:37 GMT Newsgroups: comp.lang.lisp Message-ID: <3223365881868925@naggum.net> * Kent M Pitman <pitman@world.std.com> | And there was an issue with the LispM telnet for many years regarding | asynchronous interruption--it required an extra process to listen on | the input stream and find the asynchronous-abort-request character and | process that ahead of other pending characters in order not to have | computations that just lock up and don't listen to the telnet port any | more. There may be other ways to implement this, and I don't know if | CMU's repl deals with any of this... just something to watch out for. Implementing a full TELNET client or server is about two weeks' worth of hard labor (each) for one who knows the standards involved. It is not something you whip up in an hour or two just by making or accepting connections. TELNET is a protocol that needs a dedicated programmer's full attention. Option processing in TELNET has non-trivial consequences and should not be ignored because they are mostly not used. The typical 90% solutions of TELNET server or client causes loss of data and/or lockup of the connection. In particular, interrupt processing is hard to get right. Personally, I _really_ like the Are You There facility and use it to test TELNET implementations. Very few get it right. <nostalgia Back in TOPS-10 and TOPS-20 days, and probably elsewhere, typing ^T (the canonical AYT binding), produced a system status line including system load, number of processes, what your process was doing or waiting on, etc. All extremely useful information when working a system taht occasionally went unresponsive. Sadly, the pathetic Unix terminal drivers and shells and telnet/remote shell clients are _miles_ short of the real thing.> Unfortunately, if you write a real TELNET client, nobody wants to use it, because they think the retarded HTTP-style interaction is what network protocols should be like, and the only kind of state machines programmers of today are used to working with are regular expressions, and they do not even understand how _those_ work. I fault this incredibly stupid marketing for "object-orientation" as the panacea for the demise of the state machine. /// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.