Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!brutus.cs.uiuc.edu!apple!austing From: austing@Apple.COM (Glenn L. Austin) Newsgroups: comp.sys.mac.programmer Subject: Re: Communications Toolbox questions Message-ID: <37200@apple.Apple.COM> Date: 13 Dec 89 03:21:15 GMT References: <9125@hoptoad.uucp> <36869@apple.Apple.COM> <9188@hoptoad.uucp> <37028@apple.Apple.COM> <9223@hoptoad.uucp> Organization: Apple Computer Inc, Cupertino, CA Lines: 149 In article <9223@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >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.... The manual states: Note: On a 1 megabyte Macintosh running MultiFinder (tm), you may be able to run only a single application with the Finder (tm) coresident. You may also be unable to run HyperCard (R) under MultiFinder on a 1 megabyte Macintosh with the Communications Toolbox installed. All is says is *MAY*. We *HAVE* had both CTB and HyperCard running on 1MB machines. In fact, we've even had CTB running applications on 512KE machines. I don't think that this is an issue, considering that there are many INITs that take more RAM than CTB. >>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. Yes, I am. If the uploaders of that software refuse to use the latest (and free) technology, then they are, in my opinion, making it harder, not easier to get their files. You may need this "feature", but I don't believe that your experience is as demonstrative as "reality" (whatever that is). >While we're on the subject, can you briefly sketch how an FTP protocol >tool could be created under the Communications Toolbox? First, FTP requires its own connection. This can be handled, since a hypo- thetical FTP FT tool would have the "ftSameCircuit" bit clear, which tells the application to create a new connection for the file transfer. Once that is done, the FT tool is free to use the circuit as they please. The only "magic" is that the file transfer actually occurs asynchronously, rather than "start transfer, return when complete." > >>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.... Maybe so, but the application can easily provide a vRefNum/wdNum to the FT Mgr, but it is extremely difficult to provide the "real" name of the file to download when it has not yet been received. If you want to do this, you are welcome to do so, there are no rules against it. However, I believe that you are looking at the same amount of code to implement this regardless of whether you use the CTB or not. However, without the CTB, you would also have to have information about all supported protocols and their variants -- not a trivial exercise! >>>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. You hit the point well -- how do you implement a "read" or "write" at interrupt time without affecting normal System performance. Yes, that is a problem that has been noted. No, the solution is not trivial. The major problem is, who has control of the interrupt? Sending at interrupt is a time-consuming task. AppleTalk implements it, but the maximum serial port baud rate on the Modem port drops from 57600 to 9600 -- not a small drop in performance! The answer is that there is no easy solution, and probably won't be one until an OS can be found that can preempt interrupts, regardless of state, and restore the state when the OS is done. >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. If you have a method that will work, please let me know! I don't know of any, and I have been designing electronic circuitry for 16 years and programming for 14! The only possible solution that I can see is by using coprocessors and parallel processing. >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. That would be counter-productive to "force" terminals and file transfers to have connections. There are many more applications that could use file transfer or terminal emulation (such as demos), or massage the info before the terminal or FT tool would see it. I agree that background file transfers are preferable, but I just don't see how it could be done given the current constraints upon micros. >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. Thanks for your input. I hope that you can see that we have tried to cover the concerns you have raised. >-- >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 -- ----------------------------------------------------------------------------- | 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? | -----------------------------------------------------------------------------