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

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Larry wrote on 01/30/2003 03:56:37 PM:

First Id like to say thanks for your
POP3/IMAP/LDAP reply last week.  It took a day to sink in but I finally
got it and partly answered my own question in a different thread.

> It simplifies implementations. (You do want people
to implement this,
> right?) What happens if you submit a bounded command (3 seconds,
> say), wait 3 seconds, and the server doesn't come back? What if it
> doesn't come back in 30 seconds?

This is something the draft needs to
cover (plus its not related to unbounded commands).  Thanks for raising
it.

> What if you submit an unbounded command, wait
1 second, submit a
> CANCEL, and the server still hasn't replied in 30 seconds?

This assumes that we have some CANCEL
command.  Currently we do not nor has one been actually be proposed
for inclusion yet.

ANY command could fail to get a response
so whatever solution we devise for your 1st question needs to cover them
all.

> What if the network is down or tremendously slow?

Or the CS is under very heavy load...
Or the command triggered some kind of housecleaning or fixup action on
a particular TARGET...

I don't think we've considered the case
of a CS actually being clustered and thus load balanced, etc. but that
too plays into this in the ever growing Enterprise and hosted environments.

> [...]
>    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.
> 
> How am I, as a client, suppose to know how long something is going
to
> take the server? Maybe the server is really loaded. Maybe it affects
a
> lot of data on the server.

The intent of the latency value is for
the CUA to express to the CS "This is how long Im willing to wait
to get back my results.  Check back with me then if you are not done
and see if I want to CONTINUE or not."  If the CS is heavily
loaded then of course its possible that it does not respond exactly at
the specified time with a CONTINUE command.  

Also the CUA must factor in that the
clock for latency does NOT start when the command is put on the wire to
the CS (at least in my mind) so using a local timer to say "Hey, that
stupid CS didnt complete the command in 5 seconds and I dont see a CONTINUE
command that I would therefore expect; something must be wrong!" is
not a good design.  Its also why I objected to the current draft text
that mandates "If a CS can both start sending
the reply to a command and guarantee that all of the results can be sent
from a command..." since
this kind of requirement is impossible to accurately do.

> The last thing I want, as a server, is for clients
to try an operation
> for 5 seconds, then try it for 10, then 20, etc., until it's done.

Thats exactly what LATENCY is for; so
the CUA can "give the server a little more time to complete the command".

Do you think that we need to have some
kind of minimum latency values that CS's will accept so that they can tell
CUAs "I dont care if you want results within 5 seconds, Im only going
to guarantee a minimum response time of 30 seconds"?  Or perhaps
you are thinking that bounded latency is too much to do and that it should
be optional entirely (ie: All CAP commands follow the existing POP3/IMAP/LDAP/etc
model of 'Its done when its done and if you dont want to wait then leave.")??

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