Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!linac!mp.cs.niu.edu!ux1.cso.uiuc.edu!pequod.cso.uiuc.edu!dorner
From: dorner@pequod.cso.uiuc.edu (Steve Dorner)
Newsgroups: comp.sys.mac.comm
Subject: Re: Comm Toolbox TCPtool documentation
Message-ID: <1991Mar15.170312.9266@ux1.cso.uiuc.edu>
Date: 15 Mar 91 17:03:12 GMT
References: <9263@etsu.CMI.COM> <1991Mar15.033323.19357@ux1.cso.uiuc.edu> <9288@etsu.CMI.COM>
Sender: usenet@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at U-C
Lines: 71

>Thanks for the response. Do you have any specific stories about the 
>"kinks" in Comm Toolbox.

I knew this was coming.

Let me say up front that I think the Comm Toolbox is an interesting
attempt to solve a hard problem.  I don't think the people who are
working on it are fools or idiots; I just don't think they've quite
gotten there yet.

Let me also say that my primary experience with the Comm Toolbox
involves the Apple Modem Tool, which is not terribly successful.
It's hard for me to know which bugs are really AMT bugs, and which
are really CTB bugs.  Perhaps little of this would apply to a TCP
connection tool.

1. The Apple Modem Tool misunderstands a wide variety of modems.
Sometimes this results in crashes, sometimes in refusal to make
connections.  Hidden features often (but not always) allow this to
be rectified.  These features are not documented.

2. The CTB allows you to choose whether it should report errors,
or allow your program to do so.  Unfortunately, one is never sure
just WHICH errors the CTB will report, and which it will not.
Furthermore, some tools (AMT again) will report status to the user
(dialing, retrying, etc.).  Turning off CTB error reporting turns
off these helpful status messages, too.  You can't say, "give the
user status messages but not error messages".  This is one symptom
of a broader problem; lack of fine control over what goes on.
You're pretty much stuck with how the tools behave.

3. The AMT (again) behaves differently when used synchronously or
asynchronously on some operations.  I've finally had to go to
synchronous opens and closes to avoid problems with some modems.
Apple can't reproduce the problem (they probably don't have the
right modem to do so).

4. MacTCP has SendWDS, which has spoiled me forever.  (It allows
you to send an array of pointers to MacTCP, and have the whole
bundle sent; very efficient.)  Yes, you could duplicate the behavior
with my own subroutines, but then you lose efficiency.  (Would
whoever put the wds stuff in MacTCP wander around Apple and convince
people to add them to the File manager and the CTB?  Thank you.)

5. The CTB documentation is very, very superficial.  It is possible
that I could fix or work around some problems, if I knew a little
more about the guts of the CTB and its tools.  Unfortunately, the
dox are very short on guts (but they have lots of really nice
pictures).  For example, you're encouraged to call CMIdle when
you have a connection open; should you call it when you have
an asynch open pending?  The dox are silent.

Now, an argument could be made that some of these things are
FEATURES; that my program doesn't need to know or control the gory
details, and that the whole point of the CTB is to present simple,
abstract connections to applications, and hide all the messy stuff
inside.  That would be just fine if it worked.  It currently does
NOT.

Finally, it's possible that I'm using the darn thing wrong.  I don't
know how that could be, but I've made mistakes once or twice before.
However, if it's my fault, then I'm not happy with the documentation,
cause I sure can't figure out what I'm doing wrong.

In summary, I think it's pretty easy to do a nice, efficient, robust
connection with MacTCP.  It's much harder with the CTB (at least
where some tools are concerned).  I think the extra speed and stability
makes it worth going the extra mile for MacTCP users.
--
Steve Dorner, U of Illinois Computing Services Office
Internet: s-dorner@uiuc.edu  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner