Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!decwrl!ucbvax!hoptoad!tim From: tim@hoptoad.uucp (Tim Maroney) Newsgroups: comp.sys.mac.programmer Subject: Re: Communications Toolbox questions Message-ID: <9223@hoptoad.uucp> Date: 8 Dec 89 10:36:48 GMT References: <9125@hoptoad.uucp> <36869@apple.Apple.COM> <9188@hoptoad.uucp> <37028@apple.Apple.COM> Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Eclectic Software, San Francisco Lines: 115 In article <37028@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >We've used HyperCard during our testing, both on >1MB and larger machines, with no problems. That's not what the manual says.... >Well, I'm primarily a BBS user, and I very rarely change modes. I guess you're not using the machine to get much stackware, MacPaint graphics, and so forth, out of BBS file areas. >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... I don't understand the relevance of that last comment. The issue is not alternate XMODEM implementations, but implementations of other file transfer protocols, like FTP, ZMODEM, and so forth. While we're on the subject, can you briefly sketch how an FTP protocol tool could be created under the Communications Toolbox? >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. I feel it's much more intuitive to have Standard File come up when you're creating the file, not after you've already created it. How are you supposed to choose where it goes if you don't? There are still floppy only users out there. And if you don't have a way to select the mode before you start the transfer, then you're going to have a lot of forehead-striking errors -- three minutes into your transfer, you realize you were supposed to pull down an obscure menu item before you started.... >However, >it could be done prior to starting a file transfer... There are problems with >that approach as well. Such as? I've never really considered coding it any other way. I don't like the idea of a Standard File box coming up in response to some internal invisible system event, rather than as a direct response to a user action. >>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). I don't see what you mean, sorry. I take it you are referring to the first example in Appendix B (which, by the way, needs to be broken up into about twelve subroutines to be readable -- what a mess!) This is all called in response to an idle event, so if the user decides to go browsing through the menu bar for thirty seconds, this will cause XMODEM to time out. I realize that fixing this is a serious implementation problem at your end, because it's obviously going to be difficult to get a system based on relocatable data structures to function at the clock interrupt level. Nonetheless, the misbehavior is so serious that it qualifies as a bug, and moreover, it makes hand-rolled, non-Toolbox protocols far better than Toolbox ones. It's worth your trouble to do whatever's needed to make true background transfers work. This would involve locking down all the data structures needed for FTExec to run, stashing any resource handles needed in some global data space so you don't have to touch the resource manager to get at them, locking those resources down, and (probably the most difficult thing in the current architecture) locking down the Conn. Mgr. and Term. Mgr. data structures associated with the connection as well. This is a major pain and may not even be doable; but if you have an architecture that won't allow true background file transfers, then I don't like to say this, but the market will leave you behind. If it requires, for instance, strengthening the bonds between layers so that a terminal really does have to have a connection, and a file transfer really does have to have a terminal, and the data structures are pointers rather than handles, then that's what you'll have to do. Version 2 will be too late to redefine the system this strongly; you'll be stuck with this bug, and all the major terminal emulator people will be shaking their heads sadly and saying, "We'd like to use it, but it just isn't as strong as we need". That would be sad. Overall, it's a very good piece of software, and I hope it does become the standard. (And by the way, before you start telling me how much generality would be lost by strengthening the layer bondings, let me point out that anything you can do by faking a connection, etc., can also be done by writing a special purpose tool, and that it would actually save effort in the more standard case -- for instance, the implementor of a terminal emulator wouldn't have to fill in the break and send routines. I'm probably going to do a "read from a file" or "replay" connection monitoring tool, for example, rather than faking a connection to get an exact playback mode. I think just strategically locking and stashing would be enough to allow background file transfers, if done in conjunction with closer layer binding; it probably would not be necessary to redefine the current handle data structures as pointers.) And again, with feeling: Thanks. The work you and others are putting into these answers really is helping me, even though we seem to be at odds here and there. All part of the review process. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "`Truth' never set anyone free. It is only *doubt* which will bring mental emancipation." -- Anton LaVey, quoted by Arthur Lyons, SATAN WANTS YOU