Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!austing
From: austing@Apple.COM (Glenn L. Austin)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Communications Toolbox questions
Message-ID: <37028@apple.Apple.COM>
Date: 6 Dec 89 07:44:07 GMT
References: <9125@hoptoad.uucp> <36869@apple.Apple.COM> <9188@hoptoad.uucp>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 98

In article <9188@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>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.

I agree.  We missed that one somehow.  We discussed this at length and then
forgot to notify the doc people (at least I did...).  Oh well, tech note
time, I guess... :-)

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

Just think of the overhead of another open file and the memory required for
that.  Believe me -- it's at *LEAST* the 2000% easier that Byron stated when
the CTB is in the System file rather than a separate file!  Also, the CTB needs
to load before any registration INITs, otherwise you could get an Undefined
Trap if you aren't careful (if you are, you just wouldn't get registered).

>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)?

Currently, on 1MB machines, a "small memory" model is loaded which loads the
CTB into the application heap if it is used.  On 2MB and larger, the CTB is
loaded into the System heap.  We've used HyperCard during our testing, both on
1MB and larger machines, with no problems.

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

Well, I'm primarily a BBS user, and I very rarely change modes.  However,
there may be those users who wish to change modes for each transfer.  This
could be done using the FTSetConfig call, but you need to make sure that
you are passing in the correct parameter-value pairs.  My opinion is that
anyone who writes a tool with the same name as an existing tool should at least
provide the same functionality as the existing tool...

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

Besides, at Standard File time on a file receive, you've probably already
received the file, and it would take another step to convert this.  However,
it could be done prior to starting a file transfer...  There are problems with
that approach as well.

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

Unfortunately, FTExec is not on the "approved" list of routines which can be
executed at interrupt time.  We've discussed this and still haven't figured
any good, easy-to-use, neat way to do this.  About the only way I've found is
to allow your event loop to "idle" through FTExec the same way it idles through
CMRead/TMStream (see the Useful Code Samples).
-- 
-----------------------------------------------------------------------------
| Glenn L. Austin               | "Have you ever danced with the devil in   | 
| Communications Toolbox Hacker |  in the pale moonlight?" -The Joker       |
| Apple Computer, Inc.          | "You made me!" -Batman                    | 
| Internet:   austing@apple.com |-------------------------------------------|
| AppleLink:  AUSTIN.GLENN      | All opinions stated above are mine --     |
| Bellnet:    (408) 974-0876    |                who else would want them?  |
-----------------------------------------------------------------------------