tim@hoptoad.uucp (Tim Maroney) (11/30/89)
I sent these questions to Byron Han at Apple some time ago, and it's obvious I'm not going to get an answer, so I thought I'd throw them open to the net. Any help greatly appreciated. I've been working with the Comm Toolbox and I wondered if you could give brief answers to a few questions: (1) Is there a way to configure tools "off-line", that is, without an underlying connection? The idea would be to save the configuration string in a session document, but not to start a connection. For instance, suppose you want the user to be able to configure one session document while another connection is open -- this would be pretty common: suppose the user sees the number and connection information for a great new BBS posted on a BBS she calls, and wants to set up to call the new BBS while still on-line at the old one. If the documentation says how to do so, could you point me to the appropriate place? (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. Since the installation will be as part of the system installation on 7.0, there's no need for a change there, but I trust you can see what the problems are with 6.0.x installation. It should be a file that can be dragged into the system folder. (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. (4) How does one sense a connection drop (carrier loss) on a Modem connection? (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 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? Thanks for any help you can give.... Tim Maroney, apple!hoptoad!tim -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com If you vote for clowns, you have no right to complain that only clowns make it to the ballot.
kazim@Apple.COM (Alex Kazim) (11/30/89)
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()? > >(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. > >(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. > >(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. >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. 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(). 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. Several developers have asked for this feature, and we are looking into it. 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. Hope this helps. ====================================================================== Alex Kazim, Apple Computer 2 AA Standard Disclaimers Included ======================================================================
svc@well.UUCP (Leonard Rosenthol) (12/01/89)
In article <9125@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: >I sent these questions to Byron Han at Apple some time ago, and it's >obvious I'm not going to get an answer, so I thought I'd throw them >open to the net. Any help greatly appreciated. > I'm not Byron (which may or may not be a good thing ;-), but let me see how I can do on these things... >(1) Is there a way to configure tools "off-line", that is, without an >underlying connection? The idea would be to save the configuration >string in a session document, but not to start a connection. > As far as I have been able to determine, having worked with the CTB for a while now, you can not do this. You can most certainly save off the connection information, but you have to open the connection in order to get/set the settings...I agree that this one could use work, as you point out, there are a number of reason why not to do this. >(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. >Since the installation will be as part of the system installation on >7.0, there's no need for a change there, but I trust you can see what >the problems are with 6.0.x installation. It should be a file that >can be dragged into the system folder. > The intent (last time I talked to people) was for it to be a standard INIT (at least for System 6.x) - HOWEVER do NOT assume that it will be part of System 7.0 (built in) as Apple has not yet decided how to distribute the CTB with System 7.0. Should it be an integral part of the System or an attachment like Easy Access?? 'The world may never know....' >(4) How does one sense a connection drop (carrier loss) on a Modem >connection? > I don't believe you can - at least not on Apple's Modem Tool. -- +--------------------------------------------------+ Leonard Rosenthol | GEnie : MACgician Lazerware, inc. | MacNet: MACgician UUCP: svc@well.UUCP | ALink : D0025
tim@hoptoad.uucp (Tim Maroney) (12/01/89)
Byron Han answered my questions (quite well, for the most part) and gave me permission to post his answers to the net. I thought I would do so for anyone else interested in the Toolbox issues I raised. I've trimmed his quotations of my questions. Date: 30 Nov 89 13:17:27 From: Byron Han <Byron_Han.GLASNOST@gateway.qm.apple.com> Subject: RE>Communications Toolbox To: tim@toad.com >(1) Is there a way to configure tools "off-line", that is, without an >underlying connection? The idea would be to save the configuration >string in a session document, but not to start a connection. %%%%% Yes. The connection does not have to be open and you can use CMSetConfig/GetConfig or the CMChoose routine. You can also create multiple connection records that use the same tool but each have different configurations (although they may contend for the same hardware) and can have multiple sessions going. For example, if I have a 4- port serial card I could have 6 connection records each using the serial connection tool each of which is an active session going through a different port. %%%%% >(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. %%%%% There are architectural issues as to why we are installed directly into the system file. This is because of the resource file management that we do and being in the system file makes life 2000% better under MultiFinder (far fewer games that we must play) CommToolbox 1.0 ships with Installer 3.0 which is much nicer than Installer 2.6.1 %%%%% >(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. %%%%% They will be fixed %%%%% >(4) How does one sense a connection drop (carrier loss) on a Modem >connection? %%%%% I am working on this one %%%%% >(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 >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? %%%%% Nope. I tend to use the same method every time. If you have an application with a scripting language you could configure your session document to do this thoughI %%%%% >Thanks for any help you can give.... %%%%% Sorry I took so long - my mail gets gatewayed to QuickMail and it backs up sometimes. If you like, you can post my response to the net. %%%%% End of quoted message from Byron Han. While I'm here, I might as well post my response to that message. Is anyone else interested in these issues, or should I save the bandwidth? Anyway, here's my response to Byron: Thanks very much. I didn't realize that the Comm. Mgr. would let me create a connection even if it had no spare resources. As for the installation issues, the problem has more to do with floppy disk space than the messiness of Installer. There's not enough room for both the system file w/Toolbox and the tools, so the user has to create the new folder by hand and drag the tools into it. This goes against every principle of Mac interface design I can think of.... About the status dialogs -- what I'd like to see is a callback mechanism to the application, so it could handle status changes in a way appropriate to its interface. The default would be not to use any callback, just to use the status dialogs in the system as it stands now. For instance, I prefer to show status changes with an MPW-like rectangle in the lower left corner of the window, to the left of the horizontal scroll bar. Someone who doesn't care could just use the defaults. Finally, on the "file transfer sub-protocol" issue, I *don't* use the same mode every time. It occurs to me that maybe what you're doing is transferring your own files between home and work, or something similar. Consider the issues with bulletin boards, where it's very common to have both plain ASCII text files and application/stackware/etc. files in the file area. This is how I usually use file transfer, and I hope you can see why there needs to be some kind of low-cost mode-switch operation in this case. I don't really understand how you could do this with a scripting language, as you say. How are you supposed to determine what modes are available, or what the particular protocol involved calls each mode? Leaving it up to the user is not adequate. It's occurred to me that the real problem is that these sub-protocols are a whole new layer of the system. They shouldn't be directly tied in to the file transfer tool; that leaves you having to do end-of-line conversion protocols and MacBinary over and over again, once for each transfer tool. Instead, there should be a set of low-level file transfer mode tools which the existing file transfer tools call generically to read and write Mac files. That way, when someone adds a new mode (like MacUnary), it would automatically apply to all file transfer protocols. Furthermore, applications could provide a list of available modes by using the GetInd calls to find the names of all the available mode tools. It is probably too late to include this in Comm Toolbox 1.0, but it seems to me it would definitely be worth including in a later version. Thanks again for your answers. My own mail also tends to get very late sometimes.... -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "I was brought up in the other service; but I knew from the first that the Devil was my natural master and captain and friend. I saw that he was in the right, and that the world cringed to his conqueror only from fear." - Shaw, "The Devil's Disciple"
jerryg@Apple.COM (Jerry Godes) (12/01/89)
In article <9145@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >While I'm here, I might as well post my response to that message. Is >anyone else interested in theseissues, or should I save the bandwidth? My guess is there are more people who are interested in the CommToolbox. Any issues you may have others probably do as well. >As for the installation issues, the problem has more to do with floppy >disk space than the messiness of Installer. There's not enough room >for both the system file w/Toolbox and the tools, so the user has to >create the new folder by hand and drag the tools into it. This goes >against every principle of Mac interface design I can think of.... Well, Byron has explained why we're putting the toolbox into the system itself. But, I don't think things are quite as bad as it seems... First, if you're going to use all of the tools, just drag one already named folder from the floppy onto the target. Granted it would be nicer if you didn't have to do this... The other thing is the installer scripts themselves. The final version of the installer script only installs the CommToolbox itself, not the tools. However, this script doesn't have to be the one you ship with your product. You could write your own script that installs the toolbox, the tools, and your application itself - the user won't have to drag anything. Yes, it does mean more work for you, but writing installer scripts to install entire files is pretty easy. >About the status dialogs -- what I'd like to see is a callback >mechanism to the application, so it could handle status changes in a >way appropriate to its interface... You're not the only one who wants this, this has been a common complaint since I've started to hear real developer feedback in May at the developer conference... We'll be looking into this. >Finally, on the "file transfer sub-protocol" issue I'm leaving this one alone... I'm not the expert on file transfers. You do have a valid point about the separate layer - something else we have to look into. Hope this answers some of your newer questions... Hopefully someone else will respond to the stuff that I haven't covered... Jerry Godes CommToolbox Janitor Apple Computer, Inc.
austing@Apple.COM (Glenn L. Austin) (12/01/89)
In article <9125@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: >I sent these questions to Byron Han at Apple some time ago, and it's >obvious I'm not going to get an answer, so I thought I'd throw them >open to the net. Any help greatly appreciated. > Considering how busy Byron is, I'm not surprised you haven't received an answer yet! > >I've been working with the Comm Toolbox and I wondered if you could >give brief answers to a few questions: > >(1) Is there a way to configure tools "off-line", that is, without an >underlying connection? Sure -- just use xxGetConfig and xxSetConfig. They aren't just for scripting you know... > >(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. >Since the installation will be as part of the system installation on >7.0, there's no need for a change there, but I trust you can see what >the problems are with 6.0.x installation. It should be a file that >can be dragged into the system folder. > Nope. It's part of the system, so you have to go through the installer. Sorry, but there's no real easy way around that one. > >(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. > There is a very good possibility that a majority of a user's file transfers are of the same "mode". Sorry, but I'll have to score you a miss on that one, since every other Mac communication package forces you to do the same (not that it is good, but at least it is consistent). >...I would prefer to put the mode control/pop-up >in the Standard File box itself. Is there any way to do this? > Sure, but you'd have to know what the *REAL* name of the tool is, what the range of parameters are, and so on. The CTB is supposed to ensure that the application writer *DOESN'T* need to know how to implement the parts, just that it gets done! >Thanks for any help you can give.... > No problem. Glad to help. -- ----------------------------------------------------------------------------- | 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 | | ----------------------------------------------------------------------------- | All opinions stated above are mine -- who else would want them? | -----------------------------------------------------------------------------
time@oxtrap.oxtrap.UUCP (Tim Endres) (12/02/89)
Re: Selecting the transfer mode (i.e. TEXT MacBinary etc.)... I have a program which uploads automatically, sometimes without user interaction. I do not even use SFGetFile() to obtain the SFReply, I fill it in. If I had to interact every time or select mode via dialogs every time, I could not do what I wanted. Not every use of the CTB is a terminal emulator or BBS program.
han@apple.COM (Byron Han, Project Scapegoat) (12/02/89)
In article <14778@well.UUCP> svc@well.UUCP (Leonard Rosenthol) writes: > but you have to open the connection in order to get/set > the settings... Strike 1 :-). CMGetConfig, CMSetConfig, CMSetupXXXXX calls, and CMChoose all can operate on connection records that are not open. They also work on open eonnections. > The intent (last time I talked to people) was for it to be a standard > INIT (at least for System 6.x) - HOWEVER do NOT assume that it will be part of > System 7.0 (built in) Strike 2 :-). CommToolbox IS a part of System 7.0. Period. It WILL be in the system file, not a separate file like Easy Access. > I don't believe you can - at least not on Apple's Modem Tool. Base hit! I'm looking into this one. Any suggestions would be appreciated (via e-mail please) +-------------------------------------------------------------------------+ | Disclaimer: Apple has no connection with my postings. | +-------------------------------------------------------------------------+ Byron Han, CommToolbox Scapegoat "DeAnza 3 - R.I.P. - 10/17/89 5:04PM" Apple Computer, Inc. -------------------------------- 20525 Mariani Ave, MS 69L Internet: han@apple.COM Cupertino, CA 95014 UUCP:{sun,voder,nsc,decwrl}!apple!han -------------------------------- GENIE:BYRONHAN CompuServe:72167,1664 ATTnet: 408-974-6450 Applelink:HAN1 HAN1@applelink.apple.COM ---------------------------------------------------------------------------
jerryg@Apple.COM (Jerry Godes) (12/02/89)
In article <TIME.89Dec1180135@oxtrap.oxtrap.UUCP> time@oxtrap.UUCP writes: > >Re: Selecting the transfer mode (i.e. TEXT MacBinary etc.)... > >I have a program which uploads automatically, sometimes without user >interaction. I do not even use SFGetFile() to obtain the SFReply, I >fill it in. If I had to interact every time or select mode via dialogs >every time, I could not do what I wanted. > >Not every use of the CTB is a terminal emulator or BBS program. I'm not sure exactly what you're getting at with this posting. As Alex pointed out, you can use SetConfig to set the particular mode (with the caveat that there's no way to know all of the valid options), without any user interaction. We realize that terminal emulators and BBS's are not the only use for the toolbox, that's one of the reasons we put SetConfig in there - so you can configure things without having the user go through the setup dialog. Hope this helps a bit Jerry Godes CommToolbox Janitor Apple Computer, Inc.
austing@Apple.COM (Glenn L. Austin) (12/05/89)
In article <TIME.89Dec1180135@oxtrap.oxtrap.UUCP> time@oxtrap.UUCP writes: > >Re: Selecting the transfer mode (i.e. TEXT MacBinary etc.)... > >I have a program which uploads automatically, sometimes without user >interaction. I do not even use SFGetFile() to obtain the SFReply, I >fill it in. If I had to interact every time or select mode via dialogs >every time, I could not do what I wanted. > >Not every use of the CTB is a terminal emulator or BBS program. I agree 100%. A scripting language also has the same "feature", in other words, you can specify a file name for the file before the transfer starts. All that you need to know about a tool is the format and content of the configuration string, which is pretty simple -- parameter and value, separated by a space, and all parameter-value pairs are separated with a space - pretty easy, huh? Oh, you don't even have to specify all of the parameters and values, only the parameter and value you are interested in changing! -- ----------------------------------------------------------------------------- | 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 | | ----------------------------------------------------------------------------- | All opinions stated above are mine -- who else would want them? | -----------------------------------------------------------------------------
tim@hoptoad.uucp (Tim Maroney) (12/05/89)
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
tim@hoptoad.uucp (Tim Maroney) (12/05/89)
In article <36869@apple.Apple.COM> kazim@Apple.COM (Alex Kazim) writes: >>(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. OK, this has been preying on my mind for a few hours and I have what seems to be a good answer. INITs that install Comm Toolbox resources in the linked list should not be given type INIT or RDEV to be picked up by the INIT 31 mechanism. Instead, they should be give a new type, say 'Comm', that INIT 31 won't pick up. Then the toolbox file, which *is* of type INIT or RDEV, contains its own INIT-31-type resource that only picks up files of the new type. Running INITs is pretty easy; the real INIT 31 resource is only 474 bytes of code. I think the advantages of not installing the Toolbox in the already badly overloaded System resource file speak for themselves, though I will be glad to enumerate them if necessary. I don't see any serious problems with this approach; it seems like a simple technical solution to a serious user interface issue. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "The Diabolonian position is new to the London playgoer of today, but not to lovers of serious literature. From Prometheus to the Wagnerian Siegfried, some enemy of the gods, unterrified champion of those oppressed by them, has always towered among the heroes of the loftiest poetry." - Shaw, "On Diabolonian Ethics"
jerryg@Apple.COM (Jerry Godes) (12/05/89)
In article <9188@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >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. > Ok... I'm going to attempt to answer this one for you... I just did a bit of research on my system. The statistics: System > 1 meg Systems <= 1 meg Code in System Heap 27K 2K Additional Heap Size +32K +8K The reason for the difference is the way we handle loading stuff if we're running on a smaller machine. On a large machine - all of the managers get loaded at init time into the System Heap. On the small machine - the managers get loaded at run time - into the App heap. Note: these numbers don't include the amount of memory needed for the tools themselves - this is just the managers. So, the warning is probably a bit conservative... But, it's a warning that things may not work - not that they won't work... This is probably the best place to put the response to your other posting as well: >INITs that install Comm Toolbox resources in the linked list should >not be given type INIT or RDEV to be picked up by the INIT 31 mechanism. Instead, they should be give a new type, say 'Comm', that >INIT 31 won't pick up. Then the toolbox file, which *is* of type INIT >or RDEV, contains its own INIT-31-type resource that only picks up >files of the new type. Yup - we thought of that one - I think it was even implemented in an older version of the toolbox . I don't remember all of the reasons for going back to the current method. One was probably to avoid creating another type of code resource that gets called a boot time - another different place to put viruses... There must have been more reasons - but I don't recall them right now. >I think the advantages of not installing the Toolbox in the already >badly overloaded System resource file speak for themselves, though I >will be glad to enumerate them if necessary. Well, the other thing to realize is that the CommToolbox is part of the system software. You don't say - "Well I'm not going to use the *pick your least favorite manager here* so I'm not going to install it" You install the system - and you get the system. Unfortunately, the CommToolbox is being released pre System 7.0, so we have to have our separate installation procedure until then. Once 7.0 arrives - there is no choice in the matter - the CommToolbox is installed the same way everything else in the system is installed. >While I'm here, there's one more question. Is there any way to call >FTExec at VBL time? ... 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. You guessed correctly... To make it clear - in case the documentation isn't clear: There are 3 (count 'em 3) calls that CAN be made at interrupt level - CMRead, CMWrite, CMStatus. All other calls depend on the resources being in the correct places. Again - another thing we need to add to the "next rev" wish list. Again - hope this was helpful... If you still want to argue the System File /Non System File issue - maybe we should take this to mail - I have a feeling this will be an argument where neither side is going to change their minds very quickly... Jerry Godes CommToolbox Janitor Apple Computer, Inc.
han@apple.COM (Byron Han, Project Scapegoat) (12/06/89)
In article <9194@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > Then the toolbox file, which > *is* of type INIT or RDEV, contains its own INIT-31-type resource that > only picks up files of the new type. Running INITs is pretty easy; the > real INIT 31 resource is only 474 bytes of code. We had our own INIT mechanism. We took it out. first major reason was viral protection. The second reason was why reinvent the wheel? it was yet another added piece of complexity. Furthermore, fully implementing the INIT 31 mechanism from an INIT is rather tricky if you want to deal with sysz resources and the application heap being reinitialized. CommToolbox is in the system file because it is a basic part of system software. it is not optional. that is the marketing reason. the technical reason is that under multifinder, we have to play far fewer games with resource file management if we can assume that commtoolbox resources come from the system file. the execution time binding of tools to applications does not come easily. > I don't see any serious > problems with this approach; it seems like a simple technical solution > to a serious user interface issue. It is very easy to be an armchair quarterback. One of the reasons CommToolbox took a long time from initial concept to release was that we went down a lot of blind alleys and actually had working production code that we threw away and started over to improve the user experience. +-------------------------------------------------------------------------+ | Disclaimer: Apple has no connection with my postings. | +-------------------------------------------------------------------------+ Byron Han, CommToolbox Scapegoat "DeAnza 3 - R.I.P. - 10/17/89 5:04PM" Apple Computer, Inc. -------------------------------- 20525 Mariani Ave, MS 69L Internet: han@apple.COM Cupertino, CA 95014 UUCP:{sun,voder,nsc,decwrl}!apple!han -------------------------------- GENIE:BYRONHAN CompuServe:72167,1664 ATTnet: 408-974-6450 Applelink:HAN1 HAN1@applelink.apple.COM ---------------------------------------------------------------------------
time@oxtrap.oxtrap.UUCP (Tim Endres) (12/06/89)
Tim Maroney writes: >OK, this has been preying on my mind for a few hours and I have what >seems to be a good answer. INITs that install Comm Toolbox resources >in the linked list should not be given type INIT or RDEV to be picked >up by the INIT 31 mechanism. Instead, they should be give a new type, >say 'Comm', that INIT 31 won't pick up. Then the toolbox file, which >*is* of type INIT or RDEV, contains its own INIT-31-type resource that >only picks up files of the new type. Running INITs is pretty easy; the >real INIT 31 resource is only 474 bytes of code. I must further support Tim's idea for the CTB INIT's. If my user has a one megabyte system, then pulling the CTB INIT out of the SystemFolder and rebooting to get the memory back is not a big inhibitor. BUT, running the Installer to do this is unacceptable. I think making the CTB go into the System the way it does now is a poor choice. Also, is it really necessary to even make the 'Comm' inits? Couldn't INIT 31 be made smart enough to look for CTB first? Or, couldn't the INIT 31 be programmed to look for a resource in an INIT called 'Comm' which indicates that this INIT uses the CTB, and therefore must be delayed until CTB is loaded (or possibly not loaded in case of no CTB). ANYTHING, but what is done now would be better. tim
jerryg@Apple.COM (Jerry Godes) (12/06/89)
In article <TIME.89Dec5172829@oxtrap.oxtrap.UUCP> time@oxtrap.UUCP writes: >If my user has a one megabyte system, then pulling the CTB INIT >out of the SystemFolder and rebooting to get the memory back is not a >big inhibitor. BUT, running the Installer to do this is unacceptable. >I think making the CTB go into the System the way it does now is a >poor choice. See my previous posting about this. On a one meg system, we only use 2K out of the system heap. >Also, is it really necessary to even make the 'Comm' inits? Couldn't >INIT 31 be made smart enough to look for CTB first? Yes... This could have happened - but, the problem is both timing and complexity. The CommToolbox release isn't tied to a system release - therefore, the INIT 31 can't change at the same time we release the CommToolbox. Jerry Godes CommToolbox Janitor Apple Computer, Inc.
austing@Apple.COM (Glenn L. Austin) (12/06/89)
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? | -----------------------------------------------------------------------------
austing@Apple.COM (Glenn L. Austin) (12/06/89)
In article <9194@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <36869@apple.Apple.COM> kazim@Apple.COM (Alex Kazim) writes: >>>(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. > >OK, this has been preying on my mind for a few hours and I have what >seems to be a good answer. INITs that install Comm Toolbox resources >in the linked list should not be given type INIT or RDEV to be picked >up by the INIT 31 mechanism. Instead, they should be give a new type, >say 'Comm', that INIT 31 won't pick up. Then the toolbox file, which >*is* of type INIT or RDEV, contains its own INIT-31-type resource that >only picks up files of the new type. Running INITs is pretty easy; the >real INIT 31 resource is only 474 bytes of code. We tried that -- oh how the INIT process slowed down! Just think -- most "power users" already have nearly 100 files in their System Folder (I personally had 115 until I got tired of waiting 2 minutes to start up my Mac) Every time you have to search out a file, you have to go through *ALL* the files in the System folder just to find the ones you want. Just think, first the INIT 31 mechanism starts through, then the CTB starts through the same list of files, completes, and then the INIT 31 mechanism continues with the next file -- therefore each file is touched at least twice! >I think the advantages of not installing the Toolbox in the already >badly overloaded System resource file speak for themselves, though I >will be glad to enumerate them if necessary. I don't see any serious >problems with this approach; it seems like a simple technical solution >to a serious user interface issue. I do! It takes too long already to boot up a machine, and this suggestion just doubled the time necessary! Granted, the System file is getting full, but by looking at the time and processing savings, you'll be glad it's in the System file! -- ----------------------------------------------------------------------------- | 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? | -----------------------------------------------------------------------------
austing@Apple.COM (Glenn L. Austin) (12/06/89)
In article <TIME.89Dec5172829@oxtrap.oxtrap.UUCP> time@oxtrap.UUCP writes: >Tim Maroney writes: > [text deleted] > >I must further support Tim's idea for the CTB INIT's. > >If my user has a one megabyte system, then pulling the CTB INIT >out of the SystemFolder and rebooting to get the memory back is not a >big inhibitor. BUT, running the Installer to do this is unacceptable. >I think making the CTB go into the System the way it does now is a >poor choice. On 1MB machines, the overhead is something like 440 bytes (right Byron?) from the System heap. Almost all of the rest of the overhead comes from the Application heap, and only when the toolbox is used. Why remove an integral part of System Software that uses so little memory? >Also, is it really necessary to even make the 'Comm' inits? Couldn't >INIT 31 be made smart enough to look for CTB first? Or, couldn't the >INIT 31 be programmed to look for a resource in an INIT called 'Comm' >which indicates that this INIT uses the CTB, and therefore must be >delayed until CTB is loaded (or possibly not loaded in case of no CTB). >ANYTHING, but what is done now would be better. If you look at Byron's reply in 11206, this was done for two reasons -- one of which was to close a possible loophole where a virus could invade. We worked with both the INIT and installed versions, and believe me, the installed version is *MUCH* better (we went through a few revs of the INIT version that had problems running under MultiFinder, because of the Resource Manager and the sharing of the resources in the CTB). However, by putting the code in the System file, we free up a FCB, speed up the toolbox (how's 15500 cps throughput on a 19.2K line during an XMODEM transfer!), and provide the best quality possible! -- ----------------------------------------------------------------------------- | 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? | -----------------------------------------------------------------------------
amanda@mermaid.intercon.com (Amanda Walker) (12/06/89)
In article <37029@apple.Apple.COM>, austing@Apple.COM (Glenn L. Austin) writes: > I do! It takes too long already to boot up a machine, and this suggestion just > doubled the time necessary! I'm all for keeping boot times down. Also, maybe I have a different view of the CT than Tim, but I see it not as an add-on product (such as MacTCP) but as a new piece of system software that includes a way to retrofit it into earlier versions of the System. As such, it belongs in the System, just as much as List Manager did when it came out, or the new TextEdit package, or whatever. From a pragmatic point of view, I can agree with Tim that it might be nice to be able to install & de-install the CT easily until System 7.0, but I think that the design goal of making it an integral part of the System override this concern, especially given the fact that it does take pains not to permanently gleep up a lot of memory on small machines--this makes the major concern one of disk space, as I see it. Amanda Walker InterCon Systems Corporation --
dricejb@drilex.UUCP (Craig Jackson drilex1) (12/06/89)
In article <37000@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >In article <TIME.89Dec1180135@oxtrap.oxtrap.UUCP> time@oxtrap.UUCP writes: >> >>Re: Selecting the transfer mode (i.e. TEXT MacBinary etc.)... >> >>I have a program which uploads automatically, sometimes without user >>interaction. I do not even use SFGetFile() to obtain the SFReply, I >>fill it in. If I had to interact every time or select mode via dialogs >>every time, I could not do what I wanted. >> >>Not every use of the CTB is a terminal emulator or BBS program. > >I agree 100%. A scripting language also has the same "feature", in other >words, you can specify a file name for the file before the transfer starts. >All that you need to know about a tool is the format and content of the >configuration string, which is pretty simple -- parameter and value, separated >by a space, and all parameter-value pairs are separated with a space - pretty >easy, huh? Oh, you don't even have to specify all of the parameters and values, >only the parameter and value you are interested in changing! Which still leaves the problem of having to know about the configuration string syntax of all possible tools which may be selected. I think there's an obligation on Apple's part here to at least suggest some stronger guidelines than 'parameter-value pairs'. It seems that the CommToolBox designers are expecting developers of existing scripting languages to do violence to their previous product appearance by exposing the configuration strings to the script-writer. It is far more likely that developers of such products will hard-code knowledge of the configuration strings used in the sample tools, so that the program can retain its previous interface. Possibly, they may expose the config strings in an 'Advanced User' interface. If they do not, the variety of the useful CommToolBox tools will be diminished. Because of existing scripting languages, standardization of configuration strings will occur. Wouldn't it be wiser, and more Apple-like as well, to offer some guidelines as to their contents? >| 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 | | -- Craig Jackson dricejb@drilex.dri.mgh.com {bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
vallon@sbcs.sunysb.edu (Justin Vallon) (12/07/89)
In article <TIME.89Dec5172829@oxtrap.oxtrap.UUCP> time@oxtrap.UUCP writes: >Tim Maroney writes: >>[Make a 'Comm' type which is a Comm INIT, loaded by the toolbox INIT] > >Also, is it really necessary to even make the 'Comm' inits? Couldn't >INIT 31 be made smart enough to look for CTB first? Or, couldn't the >INIT 31 be programmed to look for a resource in an INIT called 'Comm' >which indicates that this INIT uses the CTB, and therefore must be >delayed until CTB is loaded (or possibly not loaded in case of no CTB). >ANYTHING, but what is done now would be better. > >tim Two points: 1) That would mean that you would have to modify all current INIT 31's before running the Comm Toolbox. 2) Why not use the 'Comm' file-type. It is easy, prevents pointless execution of Comm INITs without Toolbox installed, and doesn't have to change anything that currently exists. -Justin vallon@sbcs.sunysb.edu
vallon@sblw.CS.SunySB.EDU (Justin Vallon) (12/07/89)
In article <4179@sbcs.sunysb.edu>, vallon@sbcs.sunysb.edu (Justin Vallon) writes: > [Stuff about 'Comm' INIT files ] > Two points: > > 1) That would mean that you would have to modify all current INIT 31's > before running the Comm Toolbox. > > 2) Why not use the 'Comm' file-type. It is easy, prevents pointless > execution of Comm INITs without Toolbox installed, and doesn't have > to change anything that currently exists. I'd like to be the first to correct myself. I hadn't read the point that the Comm file type had been tried, and it was (a) significantly slower, and (b) it required that the Toolbox init be left open :-(. Oh well. -Justin vallon@sbcs.sunysb.edu
jdevoto@Apple.COM (Jeanne A. E. DeVoto) (12/07/89)
In article <6576@drilex.UUCP> dricejb@drilex.UUCP (Craig Jackson) writes: >It seems that the CommToolBox designers are expecting developers of >existing scripting languages to do violence to their previous product >appearance by exposing the configuration strings to the script-writer. >It is far more likely that developers of such products will hard-code >knowledge of the configuration strings used in the sample tools, so that >the program can retain its previous interface. Possibly, they may expose >the config strings in an 'Advanced User' interface. If they do not, the >variety of the useful CommToolBox tools will be diminished. I don't see any reason why developers need hard-code specific strings for scripting languages. Suppose the existing syntax for setting a terminal parameter such as font size is "set terminal parameter fontSize to 9". To set this parameter using the CTB, the script interpreter would use TMSetConfig (because you are setting a terminal parameter) with the string "fontSize 9". This can be done, clearly, without the interpreter having any specific knowledge of the terminal parameters or their legal values. The *user* will need to know the parameters and values for that tool, but this information should be included in the tool documentation itself. The above configuration will return an error, by the way, since the basic terminal tools use "size" rather than "fontSize" as a parameter name. Since the character position of the bad token is returned, the script interpreter can check the string it sent against the position returned to see whether the problem is a bad parameter or bad value, and post an appropriate user error, e.g. "FontSize is not a valid parameter for the TTY terminal." Again, no special knowledge is needed by the interpreter in this example. If you want a more HyperCard-ish language with defined properties, you can do a getconfig and build a list of temporary properties from the odd-numbered tokens in the full config string. The user could then type something like "set the font to 12". Again, the only requirement is that the tools follow the guidelines for config string format. Any tool that does so will work with these schemes, and the program doesn't need to know anything about the specific tools being used. >Because of existing scripting languages, standardization of configuration >strings will occur. Wouldn't it be wiser, and more Apple-like as well, >to offer some guidelines as to their contents? Guidelines for recommended parameter and value names will be forthcoming from DTS sometime soon (most likely as a technote). -- ====== jeanne a. e. devoto ======================================== jdevoto@apple.com | You may not distribute this article under a jdevoto@well.UUCP | compilation copyright without my permission. ___________________________________________________________________ Apple Computer and I are not authorized | CI$: 72411,165 to speak for each other. | AppleLink: SQA.TEST
dricejb@drilex.UUCP (Craig Jackson drilex1) (12/08/89)
In article <37066@apple.Apple.COM> jdevoto@Apple.COM (Jeanne A. E. DeVoto) writes: >In article <6576@drilex.UUCP> dricejb@drilex.UUCP (Me) writes: >>It seems that the CommToolBox designers are expecting developers of >>existing scripting languages to do violence to their previous product >>appearance by exposing the configuration strings to the script-writer. >>It is far more likely that developers of such products will hard-code >>knowledge of the configuration strings used in the sample tools, so that >>the program can retain its previous interface. Possibly, they may expose >>the config strings in an 'Advanced User' interface. If they do not, the >>variety of the useful CommToolBox tools will be diminished. > >I don't see any reason why developers need hard-code specific strings for >scripting languages. Suppose the existing syntax for setting a terminal >parameter such as font size is "set terminal parameter fontSize to 9". >To set this parameter using the CTB, the script interpreter would use >TMSetConfig (because you are setting a terminal parameter) with the string >"fontSize 9". This can be done, clearly, without the interpreter having >any specific knowledge of the terminal parameters or their legal values. >The *user* will need to know the parameters and values for that tool, but >this information should be included in the tool documentation itself. > >The above configuration will return an error, by the way, since the basic >terminal tools use "size" rather than "fontSize" as a parameter name. Since >the character position of the bad token is returned, the script interpreter >can check the string it sent against the position returned to see whether >the problem is a bad parameter or bad value, and post an appropriate user >error, e.g. "FontSize is not a valid parameter for the TTY terminal." >Again, no special knowledge is needed by the interpreter in this example. Except that the users of that product probably don't care whether the programmer used the toolbox or did it himself; they just want it to work. And they don't want to re-write their 2000 lines of scripts just to be compatible with the new release. So if the script language already had a command 'baudrate 2400', that still has to work. Therefore, the language implementor must know to translate that to 'baud 2400' if he/she is using the toolbox. What you seem to be saying is that the tools of the CommToolBox are designed to be apparent to their end-users. That's fine, but if that is true, it will greatly lengthen the time for acceptance. For most existing communications packages, the CommToolBox will be a new submode on the side; the existing stuff will be needed, and need to be there under the same syntax. To have avoided this problem, the CommToolBox would have to have shipped around the time of the original Mac 512K.... >>Because of existing scripting languages, standardization of configuration >>strings will occur. Wouldn't it be wiser, and more Apple-like as well, >>to offer some guidelines as to their contents? > >Guidelines for recommended parameter and value names will be forthcoming >from DTS sometime soon (most likely as a technote). Fine. I'll be looking for them. BTW, shouldn't somebody tell APDA that this isn't really a Class 1 product yet? Sure looks beta-ish to me.... >-- >====== jeanne a. e. devoto ======================================== > jdevoto@apple.com | You may not distribute this article under a > jdevoto@well.UUCP | compilation copyright without my permission. -- Craig Jackson dricejb@drilex.dri.mgh.com {bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
tim@hoptoad.uucp (Tim Maroney) (12/08/89)
In article <9194@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >>OK, this has been preying on my mind for a few hours and I have what >>seems to be a good answer. INITs that install Comm Toolbox resources >>in the linked list should not be given type INIT or RDEV to be picked >>up by the INIT 31 mechanism. Instead, they should be give a new type, >>say 'Comm', that INIT 31 won't pick up. Then the toolbox file, which >>*is* of type INIT or RDEV, contains its own INIT-31-type resource that >>only picks up files of the new type. Running INITs is pretty easy; the >>real INIT 31 resource is only 474 bytes of code. In article <37029@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >We tried that -- oh how the INIT process slowed down! Just think -- most >"power users" already have nearly 100 files in their System Folder (I >personally had 115 until I got tired of waiting 2 minutes to start up my Mac) >Every time you have to search out a file, you have to go through *ALL* the >files in the System folder just to find the ones you want. Just think, first >the INIT 31 mechanism starts through, then the CTB starts through the same >list of files, completes, and then the INIT 31 mechanism continues with the >next file -- therefore each file is touched at least twice! Point 1 -- So put the bloody INITs in the Communications folder, not in the System Folder! That's probably where most users would think they belong anyway; you'll be saving everybody a bunch of support calls. Notice that the error of putting it into the System Folder rather than the Communications folder *can* be flagged by software ("You need to put this into the Communications folder instead" -- the software can even move itself there) but the opposite error cannot be automatically corrected, since an INIT placed in the Communications folder will never get run as things stand. Point 2 -- I think it's folly to have a ton of INITs and CDEVs, for reliability and compatibility reasons. It's not a configuration you should break your back to support in the friendliest way possible. Point 3 -- If the file system caching mechanism works properly, then the information on those files should still be in memory during the second loop. If the information is not still in memory, then the cache mechanism is not working properly, and should be fixed. Point 4 -- Any supposed B*-tree database manager that requires a humanly noticeable time to retrieve a mere hundred records is brain dead. >>I think the advantages of not installing the Toolbox in the already >>badly overloaded System resource file speak for themselves, though I >>will be glad to enumerate them if necessary. I don't see any serious >>problems with this approach; it seems like a simple technical solution >>to a serious user interface issue. > >I do! It takes too long already to boot up a machine, and this suggestion just >doubled the time necessary! Granted, the System file is getting full, but by >looking at the time and processing savings, you'll be glad it's in the System >file! See Point 1.... -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Don't talk to me about disclaimers! I invented disclaimers!" - The Censored Hacker
tim@hoptoad.uucp (Tim Maroney) (12/08/89)
In article <37030@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >On 1MB machines, the overhead is something like 440 bytes (right Byron?) from >the System heap. Almost all of the rest of the overhead comes from the >Application heap, and only when the toolbox is used. Why remove an integral >part of System Software that uses so little memory? The documentation is a little strange on this point; it discusses running HyperCard under MultiFinder on a 1 megabyte system. I thought 2 megabytes was considered the minimum RAM for using MultiFinder at all these days, so I read this simply as "you may be unable to run HyperCard on a 1 Meg machine with the Toolbox installed". What's the real story? Is the RAM overhead really this small on a 1 Meg machine running Finder? And why does the documentation refer to highly improbable configurations? In any case, RAM is not the only problem with putting it in the System file. System files are already too big; fetching resources from them can take seconds under some common circumstances, like having a lot of fonts installed. I think we've all seen DAs like Chooser (no Appletalk) and Control Panel take forever to come up, and these are only the most visible occurrences. Standard File seems to have the same problem, and in fact anything that uses system resources is susceptible, i.e., everything. And of course, the larger the system file, the slower Font/DA Mover will run. There's also more RAM overhead than you're taking into account. Remember the overhead in the system file resource map. And time@oxtrap has an excellent point about the ease of deinstallation and reinstallation. >We worked >with both the INIT and installed versions, and believe me, the installed >version is *MUCH* better (we went through a few revs of the INIT version that >had problems running under MultiFinder, because of the Resource Manager and the >sharing of the resources in the CTB). However, by putting the code in the >System file, we free up a FCB, speed up the toolbox (how's 15500 cps throughput >on a 19.2K line during an XMODEM transfer!), and provide the best quality >possible! Aren't you already playing some cute games to let the tool resource maps be shared between applications under MultiFinder? Why should it be any harder, or any slower, to do the same with the main Comm. Toolbox resource file? If you weren't already doing these things, I'd say you had a point; but once you take the plunge, I don't see how an inch or two more is going to hurt. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Please help support the moratorium on meaningless quotes in .signatures." -- Doug Asherman on rec.music.cd
tim@hoptoad.uucp (Tim Maroney) (12/08/89)
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
sho@maxwell.physics.purdue.edu (Sho Kuwamoto) (12/09/89)
In article <9222@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In any case, RAM is not the only problem with putting it in the System >file. System files are already too big; fetching resources from them >can take seconds under some common circumstances, like having a lot of >fonts installed. I think we've all seen DAs like Chooser (no >Appletalk) and Control Panel take forever to come up, and these are >only the most visible occurrences. What does the Control Panel have to load in from the System file? As a DA, it doesn't seem that much more complicated than other DA's, although I suppose it may be much bigger than I thought. I figured the bulk of its work was to look through the system folder to pick out the cdevs. Same thing with the Chooser. I assumed it spent most of its startup time figuring out which printers were connected, not pulling out resources from the system file. I do agree, though. The system file is way too big. What to do? I don't know. Starting with a ROM that needs less patching is a start, maybe putting some more resources in ROM would help. I'm sure everyone's had their fill of the "put the fonts in a folder, not the system file" whining. I shudder to think how big a 7.0 system file is going to be, even without a lot of fonts. The outline fonts will help reduce the space, but I'm begnning to wonder if it's going to fit on one disk... -Sho -- sho@physics.purdue.edu <<-- time to buy a bigger hard disk.
tim@hoptoad.uucp (Tim Maroney) (12/12/89)
In article <9188@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >>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. In article <5598@internal.Apple.COM> jerryg@Apple.COM (Jerry Godes) writes: >Ok... I'm going to attempt to answer this one for you... I just did a >bit of research on my system. The statistics: > System > 1 meg Systems <= 1 meg >Code in System Heap 27K 2K >Additional Heap Size +32K +8K > >Note: these numbers don't include the amount of memory needed for the >tools themselves - this is just the managers. So, the warning is >probably a bit conservative... But, it's a warning that things may not >work - not that they won't work... Strange that your numbers are so different from the other numbers we've seen here. 2K is pretty different from 440 bytes. But in any case, I accept this as a ballpark figure. May I suggest the alarmist note about memory usage be cut from the documentation? It's misleading. >>INITs that install Comm Toolbox resources in the linked list should >>not be given type INIT or RDEV to be picked up by the INIT 31 >mechanism. Instead, they should be give a new type, say 'Comm', that >>INIT 31 won't pick up. Then the toolbox file, which *is* of type INIT >>or RDEV, contains its own INIT-31-type resource that only picks up >>files of the new type. >Yup - we thought of that one - I think it was even implemented in an >older version of the toolbox . I don't remember all of the reasons for >going back to the current method. One was probably to avoid creating >another type of code resource that gets called a boot time - another >different place to put viruses... There must have been more reasons - >but I don't recall them right now. Have you seen my latest message on the subject, suggesting that the INITs be put into the Comm. Toolbox folder? Keep them in the ordinary format, but put them in a sub-folder. It should be noted that Comm. Toolbox is not the only piece of software to have this "sub-INIT" problem. There were recently a couple of messages dealing with the problems of installing protocols at INIT time under MacTCP (or *any* INIT-based TCP/IP mechanism, like TOPS TCP/IP). It is beginning to look like there should be some generally advertised method of putting INITs in a sub-folder of the system folder. INIT 31 could be hacked to look for a new resource containing a string (which contains a sub-folder name) in INIT files in the System Folder. So for instance, if you wanted MacTCP to look in a "TCP/IP" folder in the System Folder, you'd just put this string resource in the MacTCP file. INIT 31 would then, after closing the MacTCP INIT file., descend into the named folder and execute any INITs there, then return to its sweep over the System Folder. It wouldn't be at all hard to add this to INIT 31, and all protocol and communications add-ons would benefit. >Well, the other thing to realize is that the CommToolbox is part of the >system software. You don't say - "Well I'm not going to use the *pick >your least favorite manager here* so I'm not going to install it" You >install the system - and you get the system. Unfortunately, the >CommToolbox is being released pre System 7.0, so we have to have our >separate installation procedure until then. Once 7.0 arrives - there >is no choice in the matter - the CommToolbox is installed the same way >everything else in the system is installed. This is rather strange. Are you under the illusion that everyone is going to use System 7.0? System 6.0.x users will continue to have a choice in the matter of the installation of Comm. Toolbox. >>Is there any way to call FTExec at VBL time? ... I expect the answer "no"; >You guessed correctly... >Again - another thing we need to add to the "next rev" wish list. I think you need to do more than that. It may not be possible to add this feature to the architecture you have now. That would be highly unfortunate, because it would be too late to make the necessary changes to a distributed manager. You need to have at least a detailed design for this important feature before you ship your product. >To make it clear - in case the documentation >isn't clear: There are 3 (count 'em 3) calls that CAN be made at >interrupt level - CMRead, CMWrite, CMStatus. All other calls depend on >the resources being in the correct places. Why can CMRead, CMWrite, and CMStatus be called at the interrupt level? They involve a relocatable data structure describing the connection. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com FROM THE FOOL FILE: "The men promise to provide unconditionally for their wives. The women in turn serve unconditionally to provide the other household services necessary for the men to fulfill their obligations to the women. The women are satisfied because they have the men working for THEM." -- Colin Jenkins, soc.women
amanda@mermaid.intercon.com (Amanda Walker) (12/12/89)
In article <2869@pur-phy>, sho@maxwell.physics.purdue.edu (Sho Kuwamoto) writes: > I'm sure everyone's > had their fill of the "put the fonts in a folder, not the system file" > whining. I shudder to think how big a 7.0 system file is going to be, > even without a lot of fonts. Umm, according to all of Apple's blurbs so far, System 7.0 *will* be splitting out fonts, DAs, and whatnot into a (perhaps "magic") folder, so that they can be easily installed and removed with having to mess with the system file. --Amanda --
brianb@kinetics.com (Brian Bulkowski) (12/13/89)
In article <9223@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > >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? > Boy, wouldn't I like to know that too! What I'd like out of the CommTB is a generic file transfer method. For me, file transfer is broken into (at least) these parts: 1) query list of host files. 2) query list of local files. 3) get host files. 4) put local files. 5) make directories in both file structures. 6) move around in both file structures. 7) Encode or decode various file formats (XMODEM, MacBinary, ... ) I was hoping that that's what a file transfer tool would do all of these things independantly. Thus I could use my FTP interface (boy, do I like it) over LU6.2. Or FTAM. Or AFP. Is this possible? Reasonable? Brian Bulkowski Software-type-person
austing@Apple.COM (Glenn L. Austin) (12/13/89)
In article <9222@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In any case, RAM is not the only problem with putting it in the System >file. System files are already too big; fetching resources from them >can take seconds under some common circumstances, like having a lot of >fonts installed. I think we've all seen DAs like Chooser (no >Appletalk) and Control Panel take forever to come up, and these are >only the most visible occurrences. Standard File seems to have the >same problem, and in fact anything that uses system resources is >susceptible, i.e., everything. And of course, the larger the system >file, the slower Font/DA Mover will run. Look at what the Chooser and Control Panel are looking at -- all the files in the System Folder! Print drivers and other Chooser documents are just that -- documents! The same holds true for Control Panel devices, except that now the Control Panel has to open each file and determine whether or not that cdev should be shown in the list. No, you picked (in my opinion) poor examples. Better examples would be DAs that don't need external files, such as Find File or Calculator, which experience *NO* degradation in loading from a full System file! Also, Font/DA Mover has never been known as a speed demon. It works, it's a minimally used utility, and it rarely crashes. I don't think that the speed of Font/DA Mover is as much System file size (although that does contribute) as it is the function of displaying its information. Standard File, on the other hand, is limited by (1) disk access for filename lookup, (2) any FilterProcs and (3) whether your machine is doing other operations in the background. Nope, I don't see *ANYTHING* that has to really do with the size of the System file here... >There's also more RAM overhead than you're taking into account. >Remember the overhead in the system file resource map. And time@oxtrap >has an excellent point about the ease of deinstallation and >reinstallation. RAM overhead?!? What about another FCB in addition to the RAM overhead for the resource map!?! >Aren't you already playing some cute games to let the tool resource >maps be shared between applications under MultiFinder? Why should it >be any harder, or any slower, to do the same with the main Comm. >Toolbox resource file? If you weren't already doing these things, >I'd say you had a point; but once you take the plunge, I don't see >how an inch or two more is going to hurt. The *ONLY* "cute game" is the addition of a usage counter -- hardly the "hack" that you are implying. No, you have missed the whole idea -- this is System Software. System Software belongs in the System file. Period. The request for deinstalling and reinstalling the CTB is about the same as requesting that the international resources not be loaded - both would be nice for saving only about 3K of memory. Why go to that trouble when there are other, much larger users of RAM, such as virtual screens. >-- >Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com > >"Please help support the moratorium on meaningless quotes in .signatures." > -- Doug Asherman on rec.music.cd -- ----------------------------------------------------------------------------- | 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? | -----------------------------------------------------------------------------
austing@Apple.COM (Glenn L. Austin) (12/13/89)
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? | -----------------------------------------------------------------------------
dorner@pequod.cso.uiuc.edu (Steve Dorner) (12/13/89)
In article <37200@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >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. Gentle readers, Glenn obviously meant to say, "the current constraints on the Communications Toolbox," or "the constraints of the current Macintosh Operating System, especially on pre-68020 Macintoshes." I'm sure he knows of programs that do indeed transfer files in the background, even on Mac Pluses. I'm also sure he knows that there are very few constraints on "micros", and that some "micros" even have REAL OPERATING SYSTEMS that make "background file transfers" quite trivial indeed, and that some of these selfsame "micros" cost less than reasonably-configured Macintosh II's. "We just don't have the hardware" just doesn't wash anymore. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner IfUMust: (217) 244-1765
amanda@mermaid.intercon.com (Amanda Walker) (12/14/89)
In article <37200@apple.Apple.COM>, austing@Apple.COM (Glenn L. Austin) writes: > 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." The only way I see to write an FTP tool currently is to have the file transfer tool talk to MacTCP directly, bypassing the (hypothetical) Telnet tool completely. FTP requires two separate connections, one of which could be done with a Telnet connection (the command channel), but one of which is most definitely not a terminal-style connection of any sort (the data channel). The Comm Toolbox looks like a marvelous effort, but its metaphors seem to break down more and more the farther your get from a serial line... Disclaimer: I haven't actually tried writing an FTP transfer tool yet, so I may well be just confused. Amanda Walker InterCon Systems Corporation --
gjh@tybalt.caltech.edu (Greg J. Hiscott) (12/14/89)
Glenn Austin writes: >I do! It takes too long already to boot up a machine, and this suggestion just >doubled the time necessary! Granted, the System file is getting full, but by *********** >looking at the time and processing savings, you'll be glad it's in the System >file! >-- I propose we use new terminology to refer to the system file. Let us now refer to the system file as the system partition. +-------+ Greg Hiscott gophers = gophers - 7; |+-----+| gjh@ligo.caltech.edu ||[===]|| Phone:(818)356-2974 |+-----+| Disclaimer: Caltech has nothing to do with this message. +-------+ FAX:(818)304-9834
tim@hoptoad.uucp (Tim Maroney) (12/14/89)
In article <9223@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >>While we're on the subject, can you briefly sketch how an FTP protocol >>tool could be created under the Communications Toolbox? In article <872@excelan.COM> brianb@plasma.UUCP (Brian Bulkowski) writes: >Boy, wouldn't I like to know that too! What I'd like out of the CommTB >is a generic file transfer method. For me, file transfer is broken into >(at least) these parts: >1) query list of host files. >2) query list of local files. >3) get host files. >4) put local files. >5) make directories in both file structures. >6) move around in both file structures. >7) Encode or decode various file formats (XMODEM, MacBinary, ... ) > >I was hoping that that's what a file transfer tool would do all of these >things independantly. Thus I could use my FTP interface (boy, do I like it) >over LU6.2. Or FTAM. Or AFP. > >Is this possible? Reasonable? It's a good idea, and I'm planning to do something similar. There are two ways to do it, using two levels of extension mechanism. In either case, you have to add code describing these or similar operations for each shell program supporting these operations. The best way to do it is with a script language, because then power users who are not programmers can add support for new shell programs. The other way is to allow code resources (XCMD style) to be added to the program; this requires more expertise, but also gives more power and better speed. Then these "shell program tools" would call the ordinary Comm. Toolbox tools to do the low-level get and put operations. The problem is, this is not something that it would be "nice" to have with FTP; it's practically mandatory if FTP is to be usable by most users. The command set for FTP is hardly something you can expect novice users to learn and to type in raw. It seems like the only current way to implement someting like this is to have a TELNET terminal tool to the command port, then a file transfer tool that does TCP to the data port. The string to recognize an incoming file would be (let's see) oh dear, there's no single numerical code indicating that a transfer is about to start. That's a problem. How does the software know when to start up the reception? It seems as if "Receive File" will have to be special cased for an FTP connection, violating protocol independence. None of these problems are insoluble, but I would like some sign from Apple that they have at least been considered. I'm extremely disturbed that TELNET and FTP tools were not shipped with the Toolbox "beta". There are a lot of TELNET and FTP features which do not seem to be supportable, such as the OS-independent control character options in TELNET. In many ways, it looks as if this software should be called the "Modem Toolbox" instead; it certainly would not be possible to just take a multi-modem terminal emulator, plunk some new tools into the Communications folder, and have a TCP/IP terminal emulator. I think it's rather telling that no one has answered my FTP question. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Superhero stories could best be described as entertainment that externalizes childhood power fantasies." -- Timothy Fay on rec.arts.comics
tim@hoptoad.uucp (Tim Maroney) (12/18/89)
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
tim@hoptoad.uucp (Tim Maroney) (12/18/89)
In article <1621@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >The only way I see to write an FTP tool currently is to have the file transfer >tool talk to MacTCP directly, bypassing the (hypothetical) Telnet tool >completely. FTP requires two separate connections, one of which could be >done with a Telnet connection (the command channel), but one of which is >most definitely not a terminal-style connection of any sort (the data channel). > >Disclaimer: I haven't actually tried writing an FTP transfer tool yet, so >I may well be just confused. Nope, you're not confused, you're exactly right. There's a big difference between a TCP and a TELNET connection. IAC characters pass as data over a TCP connection, while they signal negotiation on a TELNET connection. If you tried to use a TELNET connection as an FTP data channel, you'd have numerous errors associated with every IAC character in the file. And if the user side TELNET connection is set up to do any automatic negotiation, then the whole thing fails. For the FTP data channel tool to set up its own TCP connection might work. Of course, you've got to find out the port of the control channel to set up the data channel, and there's no way to get this kind of information from a connection tool. And if the user types a PORT command, might as well forget about that connection.... >The Comm Toolbox looks like a marvelous effort, but its metaphors seem to >break down more and more the farther your get from a serial line... Yes, it looks like it should be called the "Modem Toolbox" as it stands now. It simply won't work for LAN functions. Maybe the solution is for Apple to hire you and me to bring it up to spec for TCP/IP.... -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Philosophy is the talk on a cereal box Religion is the smile on a dog" -- Edie Brickell, "What I Am"
6500stom@hub.UUCP (12/18/89)
>>The Comm Toolbox looks like a marvelous effort, but its metaphors seem to >>break down more and more the farther your get from a serial line... > > Yes, it looks like it should be called the "Modem Toolbox" as it stands > now. It simply won't work for LAN functions. Maybe the solution is > for Apple to hire you and me to bring it up to spec for TCP/IP.... I agree entirely. Apple should have written an External Comm Mgr that encompassed all of AppleTalk, serial ports and any other cards that might be installed. They obviously didn't think the Comm Mgr project through very well and as a result we're going to have lots of hacks floating around that bipass the weaknesses of the Comm Mgr. The big missing features are background file x-fers, serial port allocation and better support for non-modem stuff. In short, it looks like Apple bungled the Comm Mgr as badly as v 1.0 of the Sound Mgr. As least the Comm Mgr isn't as bad as the first file mgr... or is it? Its unfortunate that Apple (anyone, actually) can't get everything right the first time. / Josh Pritikin T Ignorance is bliss. \ | Internet: 6500stom@ucsbuxa.ucsb.edu | I must be in hell. | | AppleLink: Josh.P | My room is proof that entropi | \ GEnie: J.Pritikin ! exists. /
brianb@kinetics.com (Brian Bulkowski) (12/19/89)
Hi, About the CommTB and Telnet and FTP: FTP is actually even harder to impliment under the CommTB than I care to think about. One would think that you could create a special connection tool that uses 2 channels, one for the data connection, one for the control connection. Have the application do some translations between the user interface and pipe the commands over the control connection, then receive and send data over the data connection. Well, WRONG. And the problem hasn't anything to do with matching patterns, but instead creating the data connection. The data connection must be created on the fly, once per file, and the connection tool has to know what port to create it on. So unless the tool is happily parsing the control stream, it won't know 1) when to open the control stream, or 2) what port to open it on. Anyone see any REASONABLE ways around this? Telnet is actually less of a hassle than it sounds. I have implimented a simple one, and it works fine. I haven't got the finer points coded, like async calls, but it works OK nonetheless. The way to do stuff like echo negotiation is this: it only gets done once, when the connection is established, and the value must be set in the config dialog box. This means that 1) the user has to configure 2 things (the terminal and the connection), and 2) if he screws up, things will be bad. There are other negotations that are impossible, like window size negotations. As far as I can see, no professional application would use the CommTB, at least in the TCP world, because it's too simple and the state of the art (InterCon's Connect II, Novell/Kinetics' HostAccess, etc. etc.) has gone far beyond what the CommTB will offer without significant design changes. On a different note, anyone got some sample code that a tool can use to do pop up menus with the CommTB? Why isn't it in the manual how a tool creates and deals with pop up menus (arg, arg, bad doc)? There's some helpful stuff in the new code somewhere, but sometimes I can be dense. Thanks, Brian Bulkowski Software Type
austing@Apple.COM (Glenn L. Austin) (12/19/89)
In article <3352@hub.UUCP> 6500stom@hub.UUCP writes: >>>The Comm Toolbox looks like a marvelous effort, but its metaphors seem to >>>break down more and more the farther your get from a serial line... >> >> Yes, it looks like it should be called the "Modem Toolbox" as it stands >> now. It simply won't work for LAN functions. Maybe the solution is >> for Apple to hire you and me to bring it up to spec for TCP/IP.... > >I agree entirely. Apple should have written an External Comm Mgr that >encompassed all of AppleTalk, serial ports and any other cards that >might be installed. They obviously didn't think the Comm Mgr project >through very well and as a result we're going to have lots of hacks >floating around that bipass the weaknesses of the Comm Mgr. You're missing two points -- (1) external serial ports are supported, (2) to support external serial ports for AppleTalk would require a major effort from both the serial port manufacturers and the AppleTalk group. >The big missing features are background file x-fers, serial port >allocation and better support for non-modem stuff. There is *EXCELLENT* support for serial port allocation and acceptable support for non-serial connections. If people are expecting that the CTB can do specialized work that previously required an entire application to accomplish, they will be disappointed. The CTB is basically like the Device Manager - smart enough to deal with different "devices", but too low-level to maintain database structures. -- ----------------------------------------------------------------------------- | 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? | -----------------------------------------------------------------------------
tim@hoptoad.uucp (Tim Maroney) (12/19/89)
In article <898@excelan.COM> brianb@plasma.kinetics.com (Brian Bulkowski) writes: >FTP is actually even harder to impliment under the CommTB than I care to >think about. One would think that you could create a special connection >tool that uses 2 channels, one for the data connection, one for the >control connection. Have the application do some translations between the >user interface and pipe the commands over the control connection, then >receive and send data over the data connection. Well, WRONG. And the >problem hasn't anything to do with matching patterns, but instead creating >the data connection. The data connection must be created on the fly, once >per file, and the connection tool has to know what port to create it on. >So unless the tool is happily parsing the control stream, it won't know >1) when to open the control stream, or 2) what port to open it on. Yes, I referred briefly to these issues in the message you are responding to. I guess I wasn't clear. In the normal case, one has to find out the port of the terminal (TELNET) connection. There's no way to do this in the current architecture; there isn't even an extension mechanism for tools to provide non-standard services when they need to. If you have a type-through interface and the user gives a PORT command, you ain't never gonna figure out what port to use; as I said, "might as well give up on that connection". As for when to start the transfer tool, that's not insoluble under the current architecture, as long as you force the user to give a "Receive File" command *before* the actual transfer starts; the command sequence is then the same as on a normal terminal connection -- first give the typed commands to start a transfer on the other end, then select "Receive File" on your side to specify where the file should be received, then the application responds to the "Receive File" menu command by starting up the transfer. However, for the approach advocated by Glenn, where SFPutFile comes *after* the reception and the reception is triggered by a pattern on the terminal connection, it can't be done, since there's no single pattern to match to detect the beginning of a file transfer in FTP. >Anyone see any REASONABLE ways around this? I think the only way is to forget about a type-through interface and also forget about using the Communications Toolbox. The application is going to have to know about FTP and handle it itself. Regrettable, but it does seem as if FTP is too far from the domain of the Toolbox to work under it. I'm more worried about apparent incompatibilities with TELNET. >Telnet is actually less of a hassle than it sounds. I have implimented >a simple one, and it works fine. I haven't got the finer points coded, >like async calls, but it works OK nonetheless. The way to do stuff like >echo negotiation is this: it only gets done once, when the connection is >established, and the value must be set in the config dialog box. This means >that 1) the user has to configure 2 things (the terminal and the connection), >and 2) if he screws up, things will be bad. There are other negotations that >are impossible, like window size negotations. I don't consider this acceptable. The whole point of many of the TELNET options is to prevent the user from having to set things up. Your way makes this work exactly backwards -- everything has to be set up manually, and can't be fixed if it's set up wrong. And it is definitely not true that echo negotiation will only happen at the beginning of the connection; you're looking at incompatibility with any sophisticated TELNET server that turns echoing on and off in response to various program events (like password request on a normally echoing connection). (Remember, TELNET connections are supposed to echo locally to eliminate two-packet-per-keystroke overhead; it's a shame that UNIX servers usually don't do so. But some do.) >As far as I can see, no >professional application would use the CommTB, at least in the TCP world, >because it's too simple and the state of the art (InterCon's Connect II, >Novell/Kinetics' HostAccess, etc. etc.) has >gone far beyond what the CommTB will offer without significant design >changes. Let's hope you're wrong. The benefits of a Comm. Toolbox environment are many. It would be a shame if a few ill-considered code limitations got in the way of this, so that the Comm. Toolbox got added to the tech note on "Don't Abuse the Managers" which says in effect, "This is not really useful for anything serious; do it yourself with QuickDraw and the Event Manager if you want anything halfway decent". But this could happen. And in that case, so much for plug-in tools. >On a different note, anyone got some sample code that a tool can use >to do pop up menus with the CommTB? Why isn't it in the manual how >a tool creates and deals with pop up menus (arg, arg, bad doc)? There's >some helpful stuff in the new code somewhere, but sometimes I can be >dense. The beta documentation is indeed a major mess, but that's to be expected. But what's the problem with the discussion of the pop-up menu CDEF on pages 172-175? Granted, it should mention explicitly that TrackControl causes the index of the selected item to be stashed in the control value field, but that's fairly obvious. (Now I just hope that really is how it works! This seems to be very strongly implied by the comments about the minimum being set to one and the max being set to the number of items....) -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com FROM THE FOOL FILE: "Those Mayas were sacrificing not only pagan children, but baptized Christian children, for crying out loud! And they were carrying out those sacrifices, those barbarities, with great savagery, without giving the victims the benefit of the humane types of death that the European Church accorded even to heretics and witches during that century, such as burning at the stake." -- Matthew Rosenblatt, rec.arts.books
tim@hoptoad.uucp (Tim Maroney) (12/19/89)
In article <9344@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >As for when to start the transfer tool, that's not insoluble under the >current architecture, as long as you force the user to give a "Receive >File" command *before* the actual transfer starts; the command sequence >is then the same as on a normal terminal connection -- first give the >typed commands to start a transfer on the other end, then select >"Receive File" on your side to specify where the file should be >received, then the application responds to the "Receive File" menu >command by starting up the transfer. Sorry, I realized right after sending this message that this is slightly off. If you start up the RETR on the server before you start listening on the user port, then the server will get an ICMP no destination packet and abort the transfer. What you have to do is take the "Receive File" menu command first, open the user port for listening in response to this menu command, *then* send the RETR to the server. The latter part can be done by leaving the keyboard live on a type-through interface, or by sending the RETR command from software in a structured interface. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Philosophy is the talk on a cereal box Religion is the smile on a dog" -- Edie Brickell, "What I Am"
matthews@eleazar.dartmouth.edu (Jim Matthews) (12/20/89)
In article <37369@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >In article <3352@hub.UUCP> 6500stom@hub.UUCP writes: >>I agree entirely. Apple should have written an External Comm Mgr that >>encompassed all of AppleTalk, serial ports and any other cards that >>might be installed. > >You're missing two points -- (1) external serial ports are supported, >(2) to support external serial ports for AppleTalk would require a major >effort from both the serial port manufacturers and the AppleTalk group. > No, I think it's the CTB folks who are missing this point. I don't want CTB to run AppleTalk (or, more precisely, LocalTalk) off an external serial port -- I want CTB to let me use my AppleTalk network connection as a (superior) substitute for a serial line. My Mac is on a network with hundreds of thousands of interesting hosts. This network has links to Telenet, and thus to commercial services like CompuServe. It would be nice if CTB would allow me to use commercial terminal software (such as White Knight, MicroPhone, CompuServe Navigator, etc.) over this fast, convenient network connection. I think that Tim and others are complaining because CTB isn't sufficiently general -- it is locked into the world of modems and phone lines, and doesn't deal with other sorts of stream connections gracefully. At Dartmouth we've written our own, non-CTB connection tool, the Kiewit Serial Driver. It translates calls to the serial drivers into calls on a network driver, and handles things like option negotiations. So we can run White Knight, MicroPhone, and CompuServe Navigator over our net. Unfortunately, said programs are limited by the assumption that there are only two serial ports. We were hoping that CTB would invalidate that assumption in the minds of application programmers and make our software unnecessary -- it looks like we were too optimistic. Jim Matthews Dartmouth Software Development Claimer: The KSD is a really neat hack, and is the brainchild of Paul Merchant and Rich Brown. Disclaimer: KSD uses the Kiewit Stream Protocol, a locally developed AppleTalk stream protocol, so it won't be as useful on other nets. We also run a gateway that translates KSP to TCP/Telnet, and that's how we hook up with the rest of the world.
tim@hoptoad.uucp (Tim Maroney) (12/20/89)
In article <3352@hub.UUCP> 6500stom@hub.UUCP writes: >>I agree entirely. Apple should have written an External Comm Mgr that >>encompassed all of AppleTalk, serial ports and any other cards that >>might be installed. In article <37369@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: >You're missing two points -- (1) external serial ports are supported, >(2) to support external serial ports for AppleTalk would require a major >effort from both the serial port manufacturers and the AppleTalk group. Maybe I'm missing something, but I don't see what the problems are for modem servers on Appletalk, provided the protocol is a simple duplex data stream protocol. It seems that one could easily write a connection tool for such a thing, and even put the Chooser-type functionality into the configuration dialog using the new lookup interface support. Of course, the task of implementing such a tool would fall on the modem server developer; there's no pressing reason for Apple to do this. Or do you mean something else by "external serial ports on Appletalk"? >If people are expecting that the CTB can do >specialized work that previously required an entire application to accomplish, >they will be disappointed. The CTB is basically like the Device Manager - >smart enough to deal with different "devices", but too low-level to maintain >database structures. I'm also not clear on the meaning of this. First, terminal emulation and file transfer are specialized work that previously required an entire application to accomplish, and that's supposedly what the Comm. Toolbox is all about. What in particular are you exempting from the scope of the Toolbox? All LAN/WAN login services? Just FTP? Modem service? Toolbox-based BBS's? What? And what do databases have to do with anything? -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "I slept with Faith, and found a corpse in my arms on awaking; I drank and danced all night with Doubt, and found her a virgin in the morning." -- Aleister Crowley, THE BOOK OF LIES
kazim@Apple.COM (Alex Kazim) (12/20/89)
In article <17984@dartvax.Dartmouth.EDU> matthews@eleazar.dartmouth.edu (Jim Matthews) writes: >serial port -- I want CTB to let me use my AppleTalk network connection >as a (superior) substitute for a serial line. My Mac is on a network It can do this. Really. The CommToolbox itself is putting out a minimal set of tools for a number of reasons: Marketing, Developer Relations, and Resource Allocation. Let's see what other teams at Apple are doing (BTW, these were announced in June '89) - Mac X (using the CommToolbox to talk to a MacTCP tool). Gee whiz - MacX25 (includes a MacPAD tool). I use this to talk thru TELENET to Dow Jones. Well, Mr Matthews, is this what you need? - DEC LAT (I use this to talk to VMS machines. Fast.) Not announced, but I've been told I can talk about: - ADSP tool. Mac to Mac and works like a charm. I'm not sure where everyone got the idea that this is a "modem" toolbox. As you can see by the above products, we not only handle other protocols, but "gracefully" so. Did all this start because someone thought an FTP tool is impossible? If so, let's keep the discussion there. ==================================================================== Alex Kazim, Apple Computer Bo knows programming. ====================================================================
han@apple.COM (Byron Han, Project Scapegoat) (12/21/89)
I have been out of the office the last week and so am joing this discussion a bit late so I apologize for any duplication of answers In article <9325@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > 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? If you had a session using a hypothetical Telnet Connection Tool and wanted to transfer files using a hypothetical FTP File Transfer Tool, the FTP File Transfer Tool would open up a separate and orthogonal connection to the remote TCP port. Data that flows to the terminal via the Telnet port will continue to do so with the appropriate IAC characters being processed. Data that is being used for the file transfer will continue to do so via a second independent and separate data link. In article <9325@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > 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. We have found, in user testing, that this is more confusing to users. Hope this answers a few questionsI +-------------------------------------------------------------------------+ | Disclaimer: Apple has no connection with my postings. | +-------------------------------------------------------------------------+ Byron Han, CommToolbox Designer "DeAnza 3 - R.I.P. - 10/17/89 5:04PM" Apple Computer, Inc. -------------------------------- 20525 Mariani Ave, MS 69L Internet: han@apple.COM Cupertino, CA 95014 UUCP:{sun,voder,nsc,decwrl}!apple!han -------------------------------- GENIE:BYRONHAN CompuServe:72167,1664 ATTnet: 408-974-6450 Applelink:HAN1 HAN1@applelink.apple.COM ---------------------------------------------------------------------------
han@apple.COM (Byron Han, Project Scapegoat) (12/21/89)
In article <3352@hub.UUCP> 6500stom@hub.UUCP writes: > They obviously didn't think the Comm Mgr project > through very well and as a result we're going to have lots of hacks > floating around that bipass the weaknesses of the Comm Mgr. Please use the correct product name - the Macintosh Communications Toolbox. "Communications Manager" belongs to some of our esteemed competitors and we would not want to infringe on the look and feel of their name, eh? :-) > The big missing features are background file x-fers, serial port > allocation and better support for non-modem stuff. 1. I assume that you mean true background file transfers? I'll take this as a feature request... 2. By serial port allocation, I am a bit confused. The Communications Resource Manager provides support for developers to register ports with the CommToolbox which can then be accessed from an application (bypassing the Connection Manager) or via the Modem or Serial Connection Tools. 3. We are always working to improve support for all connection protocols. But keep in mind that the goal of the Connection Manager is not to expose all of the inner workings of a given connection/networking protocol but rather to present an abstraction of a data connection to the application so that the application can be written in a protocol independent fashion. +-------------------------------------------------------------------------+ | Disclaimer: Apple has no connection with my postings. | +-------------------------------------------------------------------------+ Byron Han, CommToolbox Designer "DeAnza 3 - R.I.P. - 10/17/89 5:04PM" Apple Computer, Inc. -------------------------------- 20525 Mariani Ave, MS 69L Internet: han@apple.COM Cupertino, CA 95014 UUCP:{sun,voder,nsc,decwrl}!apple!han -------------------------------- GENIE:BYRONHAN CompuServe:72167,1664 ATTnet: 408-974-6450 Applelink:HAN1 HAN1@applelink.apple.COM ---------------------------------------------------------------------------
han@apple.COM (Byron Han, Project Scapegoat) (12/21/89)
In article <898@excelan.COM> brianb@kinetics.com (Brian Bulkowski) writes: > at least in the TCP world, > because it's too simple and the state of the art (InterCon's Connect II, > Novell/Kinetics' HostAccess, etc. etc.) has > gone far beyond what the CommTB will offer without significant design > changes. Agreed! The goal of the Connection Manager is to provide applications with an interface to an abstracted concept of a connection to maximize its protocol independence. If I were to write an application to only use ADSP or only use TCP/IP, I would write directly to the driver API's. If I were to write an application to transparently access SNA, DECnet, LAT, ADSP, or TCP/IP protocols, I would use the Connection Manager API. CommToolbox is not a panacea by any stretch of the imagination... +-------------------------------------------------------------------------+ | Disclaimer: Apple has no connection with my postings. | +-------------------------------------------------------------------------+ Byron Han, CommToolbox Designer "DeAnza 3 - R.I.P. - 10/17/89 5:04PM" Apple Computer, Inc. -------------------------------- 20525 Mariani Ave, MS 69L Internet: han@apple.COM Cupertino, CA 95014 UUCP:{sun,voder,nsc,decwrl}!apple!han -------------------------------- GENIE:BYRONHAN CompuServe:72167,1664 ATTnet: 408-974-6450 Applelink:HAN1 HAN1@applelink.apple.COM ---------------------------------------------------------------------------
brianb@kinetics.com (Brian Bulkowski) (12/21/89)
In article <5894@internal.Apple.COM> han@apple.COM (Byron Han, Project Scapegoat) writes: >Agreed! The goal of the Connection Manager is to provide applications >with an interface to an abstracted concept of a connection to maximize its >protocol independence. If I were to write an application to only use ADSP >or only use TCP/IP, I would write directly to the driver API's. If I were >to write an application to transparently access SNA, DECnet, LAT, ADSP, or >TCP/IP protocols, I would use the Connection Manager API. > >CommToolbox is not a panacea by any stretch of the imagination... >Byron Han, CommToolbox Designer "DeAnza 3 - R.I.P. - 10/17/89 5:04PM" I'm not sure that it's even the panacea that it is claimed to be. I do think it is a Good Thing, and close to the panacea it should be. I'm in the situation of having to transparently access many different protocols, and it seems that the CommTB will solve a lot of our problems -- we would be writing an API for ourselves that looks like the CommTB if the CommTB weren't around. HOWEVER, The CommTB won't work well with Telnet. I think the extension that needs to be made is independant messaging. I think there should be a way for the Terminal to talk to the connection. Apple should define some standard messages, which most people could safely ignore. For example, the terminal might want to send out a "Should I local echo?" (code 1) or a "My terminal size is xx, yy" (code 2) and the connection might want to send out a "What is your window size?" (code 3)... you get the picture. Otherwise, telnet can't be supported to the level that users expect it should be. (oh, and I assume that with the integer code there should be a single pointer parameter, enginerring decision...). This mechinism would allow people who need this flexability to use it without peeking in anyone's private data structures. The problem with FTP seems bigger. I said before that I though of file transfer in a different way than the CommTB does. This can be seen in Byron's talk about FTP. Something like "If you have a Telnet connection and you want to transfer a file with FTP..." The way I think about file transfer is that there is a host, it has files, I want a list of files and want to get or put. In what I'm doing now we want to support that kind of file transfer. I will end up writing an API that allows our program protocol independant transfer. Because, as we all know, one may not have a Telnet connection when they wish to FTP a file. Same thing with LU6.2 transfers. Yah, FTP might be able to be done, but not cleanly, and the CommTB was not designed to do it. But Apple Marketing has put pressure on my Marketing people, etc. Have I said recently that I though the CommTB was a Good Thing? I do. I think it needs a few extensions, and a better manual (I have the release manual, and the tool writing section leaves a bit to be desired, I could give examples for quite a while). It's great for logging on to BBS, and might even be flexable enough for more. Brian Bulkowski software type
han@apple.COM (Byron Han, Project Scapegoat) (12/21/89)
In article <905@excelan.COM> brianb@kinetics.com (Brian Bulkowski) writes: > Because, as we all know, one may not have > a Telnet connection when they wish to FTP a file. Having a Telnet connection is NOT a prerequesite to do a FTP file transferI +-------------------------------------------------------------------------+ | Disclaimer: Apple has no connection with my postings. | +-------------------------------------------------------------------------+ Byron Han, CommToolbox Scapegoat "DeAnza 3 - R.I.P. - 10/17/89 5:04PM" Apple Computer, Inc. -------------------------------- 20525 Mariani Ave, MS 69L Internet: han@apple.COM Cupertino, CA 95014 UUCP:{sun,voder,nsc,decwrl}!apple!han -------------------------------- GENIE:BYRONHAN CompuServe:72167,1664 ATTnet: 408-974-6450 Applelink:HAN1 HAN1@applelink.apple.COM ---------------------------------------------------------------------------
alan@goofy.Apple.COM (Alan Mimms) (12/21/89)
In article <898@excelan.COM>, brianb@kinetics.com (Brian Bulkowski) writes: > Hi, > About the CommTB and Telnet and FTP: > > FTP is actually even harder to impliment under the CommTB than I care to > think about. One would think that you could create a special connection > tool that uses 2 channels, one for the data connection, one for the > control connection. Have the application do some translations between the > user interface and pipe the commands over the control connection, then > receive and send data over the data connection. Well, WRONG. And the > problem hasn't anything to do with matching patterns, but instead creating > the data connection. The data connection must be created on the fly, once > per file, and the connection tool has to know what port to create it on. > So unless the tool is happily parsing the control stream, it won't know > 1) when to open the control stream, or 2) what port to open it on. > > Anyone see any REASONABLE ways around this? There actually is a pretty reasonable way to do this that will not only work, but will be standardized in some upcoming documentation (probably a TechNote) about the connection manager. The idea is to use the CMSetConfig call to set INDIVIDUAL script variables to specify connection-tool-specific stuff like the TCP port number. If your application needs to be quite connection tool nonspecific (as does mine), you can set things in successive calls to CMSetConfig, setting a variable which many or most connection tools will understand (e.g., something like "RemoteObject"), then the specific ones for the various connection tools you know about at the time you write the application (e.g., something like "RemoteTCPPort", "RemoteADSPType", "RemoteDECnetObject", etc.). If you put the sequence of name/value pairs into a STR# resource, you can even set it up so that bizarre connection tools requirements can be easily added later. Just to whet your appetite, here's an example of the type of information we're aware of that should be included (and will) in the upcoming documentation extensions: * A complete definition of the syntax we recommend for CMSetConfig strings, including a purposefully non-exhaustive list of script variable names and their associated semantics and value syntax. * A description of suggested techniques like the one above, including some stuff about the "real" difference between the Config record and the CMSetConfig string. For example, you can use "set-only" CMSetConfig variables to turn on options in the tool that should NOT be saved in the saved connection state. These should ONLY set things in the tool for this time only and should not be returned by CMGetConfig and should not be saved in the Config record. * How to handle the situation wherein one connection tool is given some setup information via CMSetConfig, and then the user changes the currently selected tool via the CMChoose popup menu. * And much, much more... > [gratuitous (although seemingly valid) criticism of CTB deleted] > On a different note, anyone got some sample code that a tool can use > to do pop up menus with the CommTB? Why isn't it in the manual how > a tool creates and deals with pop up menus (arg, arg, bad doc)? There's > some helpful stuff in the new code somewhere, but sometimes I can be > dense. This will be documented in the new info that's coming up soon. > > Thanks, > Brian Bulkowski > Software Type I hope this helps to let you know we're on top of the problem. Alan Mimms My opinions are generally Communications Product Development Group pretty worthless, but Apple Computer they *are* my own... "The company has new jobs and Jobs has a new company" -- Harry Anderson
amanda@mermaid.intercon.com (Amanda Walker) (12/21/89)
Having nothing better to do while waiting for Fastback II to back up 144 megs to tape, I sat down and studied the latest draft of the Communications Toolbox docs, and meditated upon its relationship to TCP/IP. I think I've gotten myself a little clearer on what's going on, although I still haven't tried sitting down and writing real live code yet, so don't take the following as ultimate truth :-)... Problem 1: a Telnet connection tool. As a number of us have been noting, Telnet allows the remote host to ask for or demand actions which are user-specified over a simple terminal connection. These include most notably echoing and local editing, plus more if one wants to implement full line editing mode. There is no reason that the Telnet tool couldn't handle these, as long as it has a way to send a message back to its caller (even if it's not a terminal tool). Currently, from what I've been able to figure out, there's no reasonable way to handle this kind of dynamic reconfiguration. This is not just important for Telnet--anything that can request specific editing modes on the fly has this problem. This also goes the other way--there are terminals (such as the Zenith Z29) that allow you to change the baud rate via an escape sequence. It would be nice if there was a general way for terminal tools and connection tools to tell each other that something changed (or at least tell the application...). We've gotten a preview of this problem with our Telnet driver for VersaTerm. It works great until you talk to a host that tries to be smart, and then it can't tell VersaTerm what's going on :-). The best thing we've come up with so far is to maintain parallel state information, which seems a little silly... Problem 2: an FTP file transfer tool. There's good news and there's bad news. On the good side, it doesn't look as difficult as I thought to make an FTP tool that manages its own connections. Of course, you'll only be able to use it over TCP/IP, but since it's kind of specific to the type of connection anyway, this seems pretty irrelevant. It would still let people plug FTP into their favorite terminal program. On the bad side, I do wonder about how to handle file transfer methods like FTP that are not by nature associated with a terminal connection, and can support multiple transfers in a single session. Any way you do FTP, it seems to break the metaphor for file transfer that the Communications Toolbox uses, even though I'm more confident that it's generally possible. In short, I'm more optimistic, but I'm still not convinced that it's The Right Way yet :-). Amanda Walker InterCon Systems Corporation --
kazim@Apple.COM (Alex Kazim) (01/11/90)
In article <1645@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >on the fly has this problem. This also goes the other way--there are >terminals (such as the Zenith Z29) that allow you to change the baud rate >via an escape sequence. It would be nice if there was a general way for The problem, though, is that this assumes you're on a connection that under- stands what a baud rate is. If you were emulating a Z29 over an ADSP connection, baud rate becomes awkward. What should the ADSP tool do if someone says: "Baud Rate = 1200"? And what exactly would the host program do if its attempt to set the baud rate failed? The CommToolbox does allow the terminal & file transfer tools to peek at the connection environment, but setting it is left to the user and the application. Aside from the engineering issues, the philosophical issue of "Who's in Charge' is also present. To put your minds at some ease, we are looking into allowing some restricted tool to tool communication. So, if you've got some specific needs, let me know and we'll see what we can do. ========================================================================= Alex Kazim, Apple Computer My Lame Brained Schemes. I've never even been in a XEROX building =========================================================================