Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!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: <9188@hoptoad.uucp>
Date: 5 Dec 89 04:45:37 GMT
References: <9125@hoptoad.uucp> <36869@apple.Apple.COM>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 148

First of all, we've been having serious newsfeed problems, so we didn't
get most of the messages on this group for about the last week.  Anyone
who wrote me here and didn't get a response, that's probably the
reason.

And for those of you who seem convinced I don't know what a state
machine is, I assure you I have written protocols using both polling
and completion driven methods in my Appletalk TCP/IP work, and the
simple fact is that polling methods are easier to use.  It's not
actually so much a problem for the protocol itself as it is for the
interaction between the protocol and the synchronous-level protocol
client software.  The issue of state machines is irrelevant; all
protocols should be done this way, whether polling or interrupt-driven.
Otherwise, the code is a spaghetti nightmare.  But state machines do
not magically solve synchronous/asynchronous communication problems.

In article <36869@apple.Apple.COM> kazim@Apple.COM (Alex Kazim) writes:
>In article <9125@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes:
>>
>>(1)  Is there a way to configure tools "off-line", that is, without an
>>underlying connection?  The idea would be to save the configuration
>
>I'm not sure what you mean by "off-line".  Couldn't the user create a
>new document, configure the tools, save the doc, and then close it.  She
>hasn't actually attempted to open the connection, so she is "off-line".
>Or do you want to be able to set the configuration without having to
>perform a CMNew()/CMDispose()?

Just creating it and not opening it is fine.  I'm looking through the
manual and I can't dsee any discussion of the fact that the Open call
does check for available resources, but the New call does not.  I think
this should be considered an oversight in the documentation.

>>(2)  Are you going to make the installation process less painful for
>>users who have 6.0.x?  This is pretty important for marketing reasons.
>
>Uh, no.  We'll be using an Installer 3.0 script for the 6.0.x systems 
>to install the toolbox into the System file.  The reason is that we have
>to run before inits that register themselves with the Comm Resource Mgr.

Byron said it was because there were fewer resource manager games to play.
That makes sense (although having played a few of these games with resource
maps myself, I doubt they're really all that hard), but this doesn't.
You could easily get by with a single INIT resource in the System file.
The Comm. Toolbox file could install it itself the first time it runs.

This ties into another question -- why so much run-time overhead?  It
seems that the system assumes two megabytes.  At least, the
documentation says there's not enough free memory to run HyperCard if
you install it under on megabyte.  This says, in effect, that you are
going to piss off your users if you require Comm. Toolbox and don't
require two megabytes -- they won't be able to run major programs.
Can't the system use ememory only when it's in use (except for a few K
of always-present code)?

>>(3)  (No need to answer)  Are you aware that the status dialog boxes
>>for the Modem tool are way ugly?  They need some graphics, better
>>placement, and less need for the user to keep clicking OK.
>
>Was this the B2 APDA version?  I'll see what I can do.

Yep.  Byron seemed to like my idea for a status callback mechanism
and says it will be considered for future versions.  I'm wondering
how extensive a graphic design review has been done on the system.
The configuration dialogs are well composed, but they are littered
with meaningless graphics (especially that weird symbol in the Modem
configuration dialog -- what the heck is it supposed to be?)

>>(5)  The "sub-protocols" of file transfer are handled weakly.  The user
>>should select a mode (such as text, MacBinary, or data) every time she
>>transfers a file, sending or receiving.  It is certainly not true that
>>you will always use the same mode or sub-protocol on every file
>>transfer for a particular session document.  But the only way to do
>
>I'd debate this one.  90% of the files I transfer are TEXT, but that's
>more a reflection of life at work.  

I hope you saw my message describing how things are different for those
of us who are primarily BBS users.

>>this seems to be to follow Standard File with a complete file transfer
>>configuration dialog.  I would prefer to put the mode control/pop-up
>>in the Standard File box itself.  Is there any way to do this?
>
>This can be done a couple of ways.
>
>We can add a feature to the XMODEM tool that puts up its own SFGetFile()
>on sends and includes the protocol info. 

Ick.  I'd rather keep control over Standard File, thanks.

>The app can include a popup and call FTSetComfig() with the value.  The
>BIG problem lies in the lack of generality: the app would have to hard
>code the values of the popup, which would be fine until the user chooses
>someone's KERMIT tool which may or may not understand the FTSetConfig().

Exactly.  All that's needed is a simple routine that will return the
names of the methods and a way of saying what kinds of files can be
sent with them.  This would make this possible while preserving
protocol independence as well as error prevention.

>The reason for this is that there's no way for the app to query the 
>tool to get ALL the possible values for a given parameter.  For instance,
>give me a list of strings for all the Methods this tool supports.

*And* the information describing what kinds of files can be sent.
Otherwise, I can't do error prevention in my FileFilter.

>Several developers have asked for this feature, and we are looking into
>it.

Please, try to get this one into the first release.

>My advice, and worth every penny, would be to include a button in the
>SFGetFile() that would allow the user to bring up the configuration
>dialog if she wanted to.  That way, people like me who always use the 
>same protocol can ignore it, and people like you can bring it up.  Of
>course, you run into the ugliness of dialogs on top of dialogs.

I don't think this is really appropriate.  First, it doesn't remind
the user that it may be necessary to select a mode.  In real life
testing of TOPS Terminal, we found that without an explicit reminder,
users would generally forget to select a method, with the result that
they would often use an incorrect method.  Just having a button marked
"Configure" sitting around is nowhere near as good a reminder as having
a set of radio buttons, a list of methods, or a pop-up menu.  Furthermore,
yours is not a low-cost method switch; it's actually very high in terms
of perceived cost.  The configuration dialog takes a few second to come
up, and presents a lot of extraneous features.  It is probably a good idea
to have such a button just in case someone wants it, but for the most
common reconfiguration operation (method change), something with a lower
perceived cost needs to be available.

>Hope this helps.

Yep, thanks!

While I'm here, there's one more question.  Is there any way to call
FTExec at VBL time?  Otherwise, the protocols will have the timeout
problems already extensively discussed here.  I expect the answer "no";
I hope you realize this is a serious limitation of the system.  There
needs to be a way to do true background transfers.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"There's a real world out there, with real people.  Go out and play there for
 a while and give the Usenet sandbox a rest.  It will lower your stress
 levels and make the world a happier place for us all." -- Gene Spafford