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

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Larry noted on 01/29/2003 06:04:21 PM:
>       Establishing connections really isn't that costly
if it's only
> going to happen to what should be "rare" circumstances.

Disconnecting and restablishing a connection
(and thus reauthentication, etc) is much more costly than being able to
simply abort the command on an existing connection.   Then again unbounded
commands should be rare if not useless in our world view...

What is a good justification for having
a command that is unbounded in how long it can take AND has no means for
aborting or cancelling it short of actual disconnection from the CS?  Getting
my head around that would make swallowing this much easier...

> The addition of "cancel" and "bounded
latency" commands are more
> complicated than what's present in CAP's peer protocols (SMTP, IMAP,
> LDAP, for instance).

Adding a CANCEL command does not at
first glance appear to be that hard really.  It could be as simple
as using BEEP channel 0 to send a CANCEL command with some info needed
like the BEEP channel to cancel on.  We could include info like the
CMDID to uniquely identify the command w/in that channel if we had to.

Still, why invent more stuff if unbounded
commands do not make sense given our current model?...  Or if we are
going to keep unbounded commands then we really should expreslly codify
the way that a CUA terminates them so we have consistant behaviour among
all implementations.

I can go with the crowd on most any
solution here as long as I can at least see the rationale for the answer...

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