Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Communications Toolbox questions
Message-ID: <9344@hoptoad.uucp>
Date: 19 Dec 89 08:29:14 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>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 106

In article <898@excelan.COM> brianb@plasma.kinetics.com (Brian Bulkowski)
writes:
>FTP is actually even harder to impliment under the CommTB than I care to
>think about. One would think that you could create a special connection
>tool that uses 2 channels, one for the data connection, one for the
>control connection. Have the application do some translations between the
>user interface and pipe the commands over the control connection, then
>receive and send data over the data connection. Well, WRONG. And the
>problem hasn't anything to do with matching patterns, but instead creating
>the data connection. The data connection must be created on the fly, once
>per file, and the connection tool has to know what port to create it on.
>So unless the tool is happily parsing the control stream, it won't know
>1) when to open the control stream, or 2) what port to open it on.

Yes, I referred briefly to these issues in the message you are
responding to.  I guess I wasn't clear.  In the normal case, one has to
find out the port of the terminal (TELNET) connection.  There's no way
to do this in the current architecture; there isn't even an extension
mechanism for tools to provide non-standard services when they need
to.  If you have a type-through interface and the user gives a PORT
command, you ain't never gonna figure out what port to use; as I said,
"might as well give up on that connection".

As for when to start the transfer tool, that's not insoluble under the
current architecture, as long as you force the user to give a "Receive
File" command *before* the actual transfer starts; the command sequence
is then the same as on a normal terminal connection -- first give the
typed commands to start a transfer on the other end, then select
"Receive File" on your side to specify where the file should be
received, then the application responds to the "Receive File" menu
command by starting up the transfer.  However, for the approach
advocated by Glenn, where SFPutFile comes *after* the reception and the
reception is triggered by a pattern on the terminal connection, it
can't be done, since there's no single pattern to match to detect the
beginning of a file transfer in FTP.

>Anyone see any REASONABLE ways around this?

I think the only way is to forget about a type-through interface and
also forget about using the Communications Toolbox.  The application is
going to have to know about FTP and handle it itself.  Regrettable, but
it does seem as if FTP is too far from the domain of the Toolbox to
work under it.  I'm more worried about apparent incompatibilities with
TELNET.

>Telnet is actually less of a hassle than it sounds. I have implimented
>a simple one, and it works fine. I haven't got the finer points coded,
>like async calls, but it works OK nonetheless. The way to do stuff like
>echo negotiation is this: it only gets done once, when the connection is
>established, and the value must be set in the config dialog box. This means
>that 1) the user has to configure 2 things (the terminal and the connection),
>and 2) if he screws up, things will be bad. There are other negotations that
>are impossible, like window size negotations.

I don't consider this acceptable.  The whole point of many of the
TELNET options is to prevent the user from having to set things up.
Your way makes this work exactly backwards -- everything has to be set
up manually, and can't be fixed if it's set up wrong.  And it is
definitely not true that echo negotiation will only happen at the
beginning of the connection; you're looking at incompatibility with any
sophisticated TELNET server that turns echoing on and off in response
to various program events (like password request on a normally echoing
connection).  (Remember, TELNET connections are supposed to echo locally
to eliminate two-packet-per-keystroke overhead; it's a shame that UNIX
servers usually don't do so.  But some do.)

>As far as I can see, no
>professional application would use the CommTB, at least in the TCP world,
>because it's too simple and the state of the art (InterCon's Connect II,
>Novell/Kinetics' HostAccess, etc. etc.) has
>gone far beyond what the CommTB will offer without significant design
>changes.

Let's hope you're wrong.  The benefits of a Comm. Toolbox environment
are many.  It would be a shame if a few ill-considered code limitations
got in the way of this, so that the Comm. Toolbox got added to the tech
note on "Don't Abuse the Managers" which says in effect, "This is not
really useful for anything serious; do it yourself with QuickDraw and
the Event Manager if you want anything halfway decent".  But this could
happen.  And in that case, so much for plug-in tools.

>On a different note, anyone got some sample code that a tool can use
>to do pop up menus with the CommTB? Why isn't it in the manual how
>a tool creates and deals with pop up menus (arg, arg, bad doc)? There's
>some helpful stuff in the new code somewhere, but sometimes I can be
>dense.

The beta documentation is indeed a major mess, but that's to be
expected.  But what's the problem with the discussion of the pop-up
menu CDEF on pages 172-175?  Granted, it should mention explicitly that
TrackControl causes the index of the selected item to be stashed in the
control value field, but that's fairly obvious.  (Now I just hope that
really is how it works!  This seems to be very strongly implied by the
comments about the minimum being set to one and the max being set to
the number of items....)
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

FROM THE FOOL FILE:
"Those Mayas were sacrificing not only pagan children, but baptized
 Christian children, for crying out loud!  And they were carrying out
 those sacrifices, those barbarities, with great savagery, without
 giving the victims the benefit of the humane types of death that the
 European Church accorded even to heretics and witches during that
 century, such as burning at the stake."
		-- Matthew Rosenblatt, rec.arts.books