Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE)

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Doug wrote on 01/27/2003 06:15:35 PM:
> It disconnects on alarm. Too late to send ABORT.

If the alarm code just does the disconnect
then it can just as easily do an ABORT can't it?  What am I missing
here?

> My point is that they do not have that kind of
control. You
> have no choice - on alarm the BEEP connection is terminated
> and you can not get in side of it and send an ABORT.

This sounds like poor design if some
coded alarm system triggers terminating the transport layer session rather
than the application command in progress.  

Also, since there is network latency
involved here I find it a bit irregular that the PDA would use an internal
alarm to do some action instead of dealing w/the returned VREPLYs and the
possible TIMEOUT command from the CS.  

The previously mentioned Palm owner
questioned why the PDA app would have any timer set since there is network
latency involved and the time actually starts when the CS begins to process
the command NOT when the PDA sends it.  (Dumb design to use a local
timer that matches the requested design when you can pipeline commands
and there is latency involved he says.)

Besides, if the PDA can do some alarm
of some kind then how does that justify the use of unbounded commands?
 Ill keep searching the archives for some more justification since
it must have made sense at some point...

Bruce
===========================================================================
Bruce Kahn                  
             INet: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration            
    Phone: 978.399.6496
IBM Software Group                
        FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...