Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!bloom-beacon!mintaka!think!zaphod.mps.ohio-state.edu!mips!apple!goofy!alan
From: alan@goofy.Apple.COM (Alan Mimms)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Communications Toolbox questions
Message-ID: <5909@internal.Apple.COM>
Date: 20 Dec 89 23:26:45 GMT
References: <898@excelan.COM> <9125@hoptoad.uucp> <36869@apple.Apple.COM> <9188@hoptoad.uucp> <37028@apple.Apple.COM> <9223@hoptoad.uucp> <37200@apple.Apple.COM> <9325@hoptoad.uucp>
Sender: usenet@Apple.COM
Reply-To: alan@goofy.Apple.COM (Alan Mimms)
Organization: Apple Computer, Inc.
Lines: 78

In article <898@excelan.COM>, brianb@kinetics.com (Brian Bulkowski) writes:
> Hi,
> About the CommTB and Telnet and FTP:
> 
> 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.
> 
> Anyone see any REASONABLE ways around this?

There actually is a pretty reasonable way to do this that will not only
work, but will be standardized in some upcoming documentation (probably
a TechNote) about the connection manager.

The idea is to use the CMSetConfig call to set INDIVIDUAL script variables
to specify connection-tool-specific stuff like the TCP port number.

If your application needs to be quite connection tool nonspecific (as
does mine), you can set things in successive calls to CMSetConfig, setting a
variable which many or most connection tools will understand (e.g.,
something like "RemoteObject"), then the specific ones for the various
connection tools you know about at the time you write the application
(e.g., something like "RemoteTCPPort", "RemoteADSPType",
"RemoteDECnetObject", etc.).  If you put the sequence of name/value
pairs into a STR# resource, you can even set it up so that bizarre
connection tools requirements can be easily added later.

Just to whet your appetite, here's an example of the type of information
we're aware of that should be included (and will) in the upcoming
documentation extensions:

* A complete definition of the syntax we recommend for CMSetConfig strings,
  including a purposefully non-exhaustive list of script variable names
  and their associated semantics and value syntax.

* A description of suggested techniques like the one above, including
  some stuff about the "real" difference between the Config record and
  the CMSetConfig string.  For example, you can use "set-only" CMSetConfig
  variables to turn on options in the tool that should NOT be saved in
  the saved connection state.  These should ONLY set things in the tool
  for this time only and should not be returned by CMGetConfig and should
  not be saved in the Config record.

* How to handle the situation wherein one connection tool is given some
  setup information via CMSetConfig, and then the user changes the
  currently selected tool via the CMChoose popup menu.

* And much, much more...

> [gratuitous (although seemingly valid) criticism of CTB deleted]

> 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.

This will be documented in the new info that's coming up soon.

> 
> Thanks,
> Brian Bulkowski
> Software Type

I hope this helps to let you know we're on top of the problem.

Alan Mimms                                      My opinions are generally
Communications Product Development Group        pretty worthless, but
Apple Computer                                  they *are* my own...
"The company has new jobs and Jobs has a new company" -- Harry Anderson