Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!intercon!amanda@mermaid.intercon.com
From: amanda@mermaid.intercon.com (Amanda Walker)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Communications Toolbox questions
Keywords: Telnet FTP
Message-ID: <1645@intercon.com>
Date: 21 Dec 89 02:58:45 GMT
References: <9125@hoptoad.uucp> <36869@apple.Apple.COM> <9188@hoptoad.uucp> <37028@apple.Apple.COM> <9223@hoptoad.uucp> <37200@apple.Apple.COM> <9325@hoptoad.uucp> <898@excelan.COM> <5894@internal.Apple.COM> <905@excelan.COM>
Sender: news@intercon.com
Reply-To: amanda@mermaid.intercon.com (Amanda Walker)
Organization: InterCon Systems Corporation
Lines: 49

Having nothing better to do while waiting for Fastback II to back up 144 megs
to tape, I sat down and studied the latest draft of the Communications
Toolbox docs, and meditated upon its relationship to TCP/IP.  I think I've
gotten myself a little clearer on what's going on, although I still haven't
tried sitting down and writing real live code yet, so don't take the following
as ultimate truth :-)...

Problem 1: a Telnet connection tool.

As a number of us have been noting, Telnet allows the remote host to ask
for or demand actions which are user-specified over a simple terminal
connection.  These include most notably echoing and local editing, plus
more if one wants to implement full line editing mode.  There is no
reason that the Telnet tool couldn't handle these, as long as it has a
way to send a message back to its caller (even if it's not a terminal
tool).  Currently, from what I've been able to figure out, there's no
reasonable way to handle this kind of dynamic reconfiguration.  This is not
just important for Telnet--anything that can request specific editing modes
on the fly has this problem.  This also goes the other way--there are
terminals (such as the Zenith Z29) that allow you to change the baud rate
via an escape sequence.  It would be nice if there was a general way for
terminal tools and connection tools to tell each other that something
changed (or at least tell the application...).

We've gotten a preview of this problem with our Telnet driver for VersaTerm.
It works great until you talk to a host that tries to be smart, and then
it can't tell VersaTerm what's going on :-).  The best thing we've come up
with so far is to maintain parallel state information, which seems a little
silly...

Problem 2: an FTP file transfer tool.

There's good news and there's bad news.  On the good side, it doesn't look
as difficult as I thought to make an FTP tool that manages its own connections.
Of course, you'll only be able to use it over TCP/IP, but since it's kind
of specific to the type of connection anyway, this seems pretty irrelevant.
It would still let people plug FTP into their favorite terminal program.
On the bad side, I do wonder about how to handle file transfer methods
like FTP that are not by nature associated with a terminal connection, and
can support multiple transfers in a single session.  Any way you do FTP,
it seems to break the metaphor for file transfer that the Communications
Toolbox uses, even though I'm more confident that it's generally possible.

In short, I'm more optimistic, but I'm still not convinced that it's The
Right Way yet :-).

Amanda Walker
InterCon Systems Corporation
--