Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!excelan!brianb
From: brianb@kinetics.com (Brian Bulkowski)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Communications Toolbox questions
Message-ID: <905@excelan.COM>
Date: 20 Dec 89 19:35:24 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>
Sender: news@excelan.COM
Reply-To: brianb@plasma.kinetics.com (Brian Bulkowski)
Organization: Novell Corp., Walnut Creek, CA.
Lines: 53

In article <5894@internal.Apple.COM> han@apple.COM (Byron Han, Project Scapegoat) writes:
>Agreed!  The goal of the Connection Manager is to provide applications 
>with an interface to an abstracted concept of a connection to maximize its 
>protocol independence.  If I were to write an application to only use ADSP 
>or only use TCP/IP, I would write directly to the driver API's.  If I were 
>to write an application to transparently access SNA, DECnet, LAT, ADSP, or 
>TCP/IP protocols, I would use the Connection Manager API.
>
>CommToolbox is not a panacea by any stretch of the imagination...
>Byron Han, CommToolbox Designer  "DeAnza 3 - R.I.P. - 10/17/89 5:04PM"

I'm not sure that it's even the panacea that it is claimed to be. I do
think it is a Good Thing, and close to the panacea it should be. I'm in
the situation of having to transparently access many different protocols,
and it seems that the CommTB will solve a lot of our problems -- we would
be writing an API for ourselves that looks like the CommTB if the CommTB
weren't around.

HOWEVER,
The CommTB won't work well with Telnet. I think the extension that needs
to be made is independant messaging. I think there should be a way for
the Terminal to talk to the connection. Apple should define some standard
messages, which most people could safely ignore. For example, the terminal
might want to send out a "Should I local echo?" (code 1) or a "My terminal
size is xx, yy" (code 2) and the connection might want to send out a
"What is your window size?" (code 3)... you get the picture. Otherwise,
telnet can't be supported to the level that users expect it should be.
(oh, and I assume that with the integer code there should be a single
pointer parameter, enginerring decision...). This mechinism would allow
people who need this flexability to use it without peeking in anyone's
private data structures.

The problem with FTP seems bigger. I said before that I though of file
transfer in a different way than the CommTB does. This can be seen
in Byron's talk about FTP. Something like "If you have a Telnet connection
and you want to transfer a file with FTP..." The way I think about file
transfer is that there is a host, it has files, I want a list of files
and want to get or put. In what I'm doing now we want to support that
kind of file transfer. I will end up writing an API that allows our program
protocol independant transfer. Because, as we all know, one may not have
a Telnet connection when they wish to FTP a file. Same thing with LU6.2
transfers. Yah, FTP might be able to be done, but not cleanly, and the
CommTB was not designed to do it. But Apple Marketing has put pressure
on my Marketing people, etc.

Have I said recently that I though the CommTB was a Good Thing? I do.
I think it needs a few extensions, and a better manual (I have the
release manual, and the tool writing section leaves a bit to be desired,
I could give examples for quite a while). It's great for logging on
to BBS, and might even be flexable enough for more. 

Brian Bulkowski
software type