Xref: utzoo comp.sys.mac.comm:1245 comp.sys.mac.programmer:18242 Path: utzoo!attcan!uunet!ns-mx!iowasp.physics.uiowa.edu!maverick.ksu.ksu.edu!rutgers!ucsd!ucbvax!unisoft!hoptoad!tim From: tim@hoptoad.uucp (Tim Maroney) Newsgroups: comp.sys.mac.comm,comp.sys.mac.programmer Subject: Re: Communications Toolbox TCP Tool Needed Message-ID: <12833@hoptoad.uucp> Date: 13 Oct 90 10:48:34 GMT References: <0B030501.QKT1KD@tbomb.ice.com> <1545@howtek.UUCP> <114@pacvax.UUCP> <12765@hoptoad.uucp> <115@pacvax.UUCP> <12811@hoptoad.uucp> Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Electronics for Imaging, San Bruno CA Lines: 69 In article <12811@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: >> Very interesting. How do you deal with TELNET options that control things >> that live in the terminal layer of CTB? In article amanda@visix.com (Amanda Walker) writes: >That's the fun part! :-). The only effective way is to do things >like: > Local echo > Local line editing > Control character -> Telnet control translation > >and suchlike *within* the connection tool. It's gross, but it works, >and it's the only way to keep the CTB and modern Telnet servers happy. It's a clever solution, but it has its own problems. If your application tries to manage control characters, local line editing, and local echo itself at user request (as TOPS Terminal does, except for local line editing), for instance by providing a universal set of control characters which, for modem connections, are mapped to the OS control characters but for a TELNET connection, are mapped to the TELNET standard control sequences, then there's no way for this scheme to work without explicit agreement between the application and the tool, which is not supposed to be needed and which violates the transparent plug-in concept. Similarly for local editing and local echo; the user can't specify these in a tool-independent way, and any setting made at the terminal tool level will be ignored. In case anyone thought I was implicitly criticizing Pacer for the likely limitations of their tools, please accept my apologies for my lack of clarity. I am actually criticizing Apple for the lack of generality in the Communications Toolbox, which Amanda, myself, and others made abundantly clear to them quite a while ago. So far, there is no word on a more general upgrade that would solve the TCP/IP incompatibility issues. Apple has a strange habit of releasing supposedly general-purpose software without actually implementing hard test cases which would prove the software to be general. I could point out, for instance: Communications Toolbox MacApp (until this year) TextEdit (now not recommended for serious development) Dialog Manager (now not recommended for serious development) Script Manager (until the second release) B*-Tree Manager (except they scrapped it instead of generalizing it) On the other side, we have all the software which is supposed to be general-purpose and of great use to developers, and which was actually tested by the implementation of significant test cases before release: Mac Programmer's Workshop HyperCard In the more common non-general case, obvious test cases were ignored, such as word processors, sophisticated control panel type dialogs, TCP/IP communications, graphics terminals, real databases, HyperCard-type applications, and so on. What could possibly have been going through the minds of the programmers and product managers? How could any serious developer announce that software is general-purpose when it has not yet been used for general purposes? -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "When errors are found in old research, the relevant theories are re-examined. When facts contradict theory, theory gets dumped. Is that why the NLP people are unwilling to research their facts?" -- Jerry Hollombe on sci.psychology