Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!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: <9325@hoptoad.uucp> Date: 18 Dec 89 01:42:34 GMT References: <9125@hoptoad.uucp> <36869@apple.Apple.COM> <9188@hoptoad.uucp> <37028@apple.Apple.COM> <9223@hoptoad.uucp> <37200@apple.Apple.COM> Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Eclectic Software, San Francisco Lines: 145 In article <37028@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >>>Well, I'm primarily a BBS user, and I very rarely change modes. In article <9223@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >>I guess you're not using the machine to get much stackware, MacPaint >>graphics, and so forth, out of BBS file areas. In article <37200@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >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). What are you saying here? That everything should be binhexed? I don't agree at all; MacBinary format is far more convenient for the user. To use BinHex, you have to download the file as text, then launch a utility to decode it, then quit the utility, then throw away the original file. MacBinary mode is more convenient; the file arrives complete and intact. I might also note that BinHex is *not* free; it's shareware. It won't be shipped with the Communications Toolbox either, so most users won't have it. >>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." As Amanda has pointed out, the two connections are *not* of the same type. There are other problems as well; for instance, there is no single pattern to match to signal that a download is starting. And how do you handle the user interface, where both TELNET and FTP use the same connection protocol, but to different ports? Is the user expected to configure the connection tool with a port number? I think there are a number of unresolved issues concerning TELNET and FTP, and I remain highly disturbed that no connection and file transfer tools are available. I've been saying this for some nine months now, and there still isn't a TELNET or FTP tool. Is this because there are technical difficulties in creating these tools, or do you simply not care about TCP/IP support? Here's another unresolved issue, for instance. How does a TELNET tool handle the highly important local echo options, when the TELNET tool is a connection tool, but the local echo setting is controlled by the terminal tool? You can't go from connection to terminal tool in the current architecture. But without local echo negotiation, you can't run TELNET. >>>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! The "real" name of the file may or may not be there, depending on the protocol and the transfer method. XMODEM does not ordinarily contain it, but it does in MacBinary mode (which you seem to be saying above no one should use.) So you have to assume that the name is unknown, letting the user type it in, and then letting the file transfer tool change it if it wants. I don't understand the relevance of your comments on code size. I thought what we were discussing was the ability to select a file transfer method from Standard File. >>>>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. >>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. I must not have been clear. Performance is not the issue; relocatability is the issue. A system based on relocatable handles and resource fetches simply can't be run at clock interrupt time, performance issues aside. That is, unless you implement code to lock down all the handles and pre-fetch and stash all the resources. The system you have can't do this, because there's no way for the Toolbox to determine what other tools (terminal and connection) are associated with a file transfer. >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. > >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 rather disingenuous, since we've just had a lengthy discussion concerning the fact that VersaTerm does exactly this, apparently through a system heap VBL task. It can be done on the Mac; if the Toolbox can't do it, then that's the fault of the Toolbox, not the Mac OS in general. I accept that this may be a problem for transfers at higher baud rates than 9600 baud, but that is not the usual case. Direct serial port connections of this kind are now out of fashion; they have mostly been replaced by local area networks. Even most places that still run direct serial ports into offices and clusters use port selectors that run at no higher than 9600 baud. And it will be a few years before a significant number of phone line users have modems capable of more than 9600 baud; in fact, most of us are not up to 9600 baud yet. If you were simply to turn off the VBL for high-bandwidth users, the rest of us could still have what we need. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "And did you ever stop to think that Tim may be doing something right by being so controversial? I mean, he may be an asshole but at least he's an intelligent asshole. I do have to admit his articles tend to entertain me, although I kill the resulting flame wars." -- maxc1142@ucselx.sdsu.edu