From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.comm
Subject: Re: MacIntercomm (finally a real comm program)
Date: 6 Oct 92 11:07:08 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <1992Oct5.173125.686@muddcs.claremont.edu>, jam@jupiter.claremont.edu (Jay Margolis) writes:
> 
> Let's be realistic, virtually everything one would normally want to do  
> takes up too much time in a normal situation, and results in slowing down  
> a transfer.  

That has not been my experience. Indeed, I have even done COMPILES under 
MPW during file transfers.

> I will grant that usually other old comm programs like  
> SmartCom wont crash, but they certainly abort the transfer.  

My experience has been that it is extremely difficult to get Smartcom to
abort a transfer with normal Macintosh use. And the use of the term "crash"
in the original posting was certainly unjustified.

> I guess I misstated myself.  The thing is that you say, how often do you do 
> these things that slow the computer down?  Well I would say often.  Things 
> like formatting a disk, stuffing a file, unstuffing, booting an application,  
> holding down a menu, playing virtually ANY game, working with a complex  
> spreadsheet, using a large database, printing, etc...  

Formatting a disk stops the machine cold. Some of these other items will rob
time from an application, but won't bring the machine to a halt. Booting
an application is a transitory thing (you aren't booting applications every
moment, usually you stop to use them after booting)

Sure, these things will make a transfer take a bit longer. Most of the time,
it doesn't matter. If you are downloading from a local BBS, it won't
matter if it takes, say, 10% longer. You're doing useful work in the meantime.
So what if the transfer pauses for 3 seconds while you boot and application,
the computer is doing useful work in the meantime.

> Take that list and I am doing one of those things about 70% of the time.  
> I can't do any of those things during a file transfer with any of the 
> existing comm software besides MacIntercomm without significantly slowing 
> or aborting my transfer.  

Apparently, you feel that a transfer slowdown of a few percent is "significant".
I do not. Furthermore, it has been my experience with Smartcom that you need
to take drastic action to abort a transfer. Perhaps you spend all of your
time formatting floppies during downloads. 

> This is not only apparent at V.32bis where the timing is crucial, but 
> perhaps even more so at 2400 baud where response time in many protocols 
> is imperative.  

Come on. I write protocols. I wrote the excellent Kermit for Smartcom, I wrote
CIS B plus. The timing isn't that critical. If it is, something is either 
wrong with the implementation, or something is wrong with the protocol 
specification. All the common transfer protocols (XYZmodem, Kermit, etc)
can take several seconds of no activity without damage. To abort a transfer
requires sustained inactivity for minutes. (Example, XMODEM will retry
10 times every 10 seconds. That's 100 seconds until it aborts)

The timing isn't that critical with respect to speed. Indeed, at 2400, timing
is less critical than at higher speeds.

Jay, I don't think you know that much about the operation of file transfer
protocols, otherwise you wouldn't make such misleading statements.

> I have a suggestion.  Go play After Dark's Lunatic Fringe module while you 
> do a high speed transfer.  Play for 30 seconds.  Bye bye transfer.  

If I was using XMODEM, this wouldn't happen. I'd have to play for 100 seconds,
provided Lunatic Fringe fails to every release any CPU time to any application.
If that were true, it would make a terrible screen saver. 

Kermit would take 5 tries at 15 seconds, that's 75 seconds, still not enough.

Then again, when I play Lunatic Fringe, I don't want anything else going on
in my Mac. I want all the speed I can muster for the cool animation.

> SmartCom and others don't do anything in the background.  

Smartcom and others *DO* do things in the background. I asserted this was so.
I never said otherwise. They work cooperatively with other applications 
according to the guidelines set up by Apple.

> That's laughable.  They use the Multifinder HACK that is Apple's sorry 
> excuse for multitasking which clearly doesn't work for things like comm 
> programs.   

Funny, it has been working fine (and without change) for 5 years with
Smartcom. That's through three major releases of the OS (System 5,6 and 7).

> MacIntercomm is the only program I know of that can really do  
> backgrounding, and to downplay that seems like bad sportsmanship.

I'm not downplaying MacIntercomm's multitasking capability. Read my 
original posting, I stated repeatedly that this feature was unique.

I was however, trying to correct the misconception that this capability is
necessary for background file transfer. It isn't. I've been doing
background file transfers for years, and I don't have MacIntercomm.

I'm just trying to set the record straight.

It is fine to be excited about the features of a new product. Just don't
let your enthusiasm cloud reality.

-- 
Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
Disclaimer: "My employer doesn't pay me to have opinions."
Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.