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

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Doug wrote on 01/24/2003 12:40:50 PM:
> > If a CUA does not support latency then just how would it be able
to 
> > control/stop a command it issued?
...
> Many PDAs for example have a time out or alarm
then they simply
> assume the remote end is not responding. 

Ok, Im trying to not be dense but your
PDA w/alarms CAN do latency since it obviously has the ability to deal
with time outs, etc.  Is there a real case where a CUA does NOT have
this ability and is it a likely candidate for hosting something as robust
as CAP?  (Ok I digress a bit but it helps me think sometimes...)

>              
                     
 They do not want the
> user to have to wait for another time out period sending
> an ABORT that may also time out because the other endpoint
> is down.

Umm, network disconnects were not part
of this discussion so far; lets keep it simple and just focus on the case
of controlling unbounded commands.

> Any CUA may send an ABORT. As CELL based CUA's
use air time
> (like my Kyocera), I do not want to wait for a few more minutes
> to see if the other end is responding. Simply disconnect.

I havent seen any text/requirement that
a CS must support multiple concurrent commands on the same BEEP channel.
 As such, if the unbounded command is going on then when would/should/can/MUST(?)
the CS do any command polling for new commands on the same channel to detect
the ABORT command?  (Is this something in BEEP that Ive just overlooked
or forgotten over the holidays?)

> And some CS's might not support LATENCY. If my
cell-PDA contacts
> your cell-PDA - one will be a CS and it might not be able to
> do timed calculations. That is I can set the time out on the cell-PDA
> but that aborts the transaction and connection and no way to
> send an ABORT or TIMEOUT.

Is it really likely that a PDA that
has no ability to do timers or alarms is going to really host a CS??  Doesnt
sound like it to me.  Sure, there will be someone out there who may
want to write one to prove me wrong but they wont be anywhere near the
majority I bet.

Hmm, your last bit sounds like it agrees
with my question about about being able to send an ABORT to a CS who is
going unbounded.  But I think its slightly different too.  One
case is a CS cannot support latency (and Ive yet to see an example of a
'server' CS that would not be able to support latency) and the other flavor
is that both sides DO support bounded latency but the command was NOT bounded.
 Just how is the latter case controlled short of disconnecting?

>  > That is, if the Palm CUA sent a
> > search that was taking a long time (a very busy and impatient
exec) and 
> > the CU wanted to stop the action then just how would the CU/CUA
be able 
> > to do that if they didnt support at least ABORT?  (Clearly
CONTINUE is 
> > irrelvant to this discussion).  The only way if ABORT is
not supported 
> > by all implementations is to disconnect from the CS and then
reconnect 
> > back...  Ack!
> 
> In some PDAs that is the only option.

Thats like telling a user they have
to reboot their computer to exit from their mail reader.  Ugh!! 

Still, if that is the only option then
I think we should put that into the draft as a big cavat to bounded latency
so its perfectly clear what the consequences are of unbounded commands.

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...