Re: CAP 10: CREATE Command and ordering of responses.

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Doug responded on 02/21/2003 01:39:35 PM:
> It overlaps exactly the same as if two commands have been
> each done separately - in the case of delete it can not
> overlap because the 1st would have already deleted any overlaps.
> Correct?

Not true for the DELETE command.  Ok,
back to the "All VEVENTS last week" AND "VEVENT with UID:12345@QWERTY"
case for this.  Ordering here can and will produce DIFFERENT results
in the DELETE command:

1. If the "All VEVENTs last week" deletion is done first then there will be a delete-vreply with UID:12345@QWERTY in it and a REQUEST-STATUS:2.0;The events gone! property as well so the CUA can see that it was deleted.  So when the "VEVENT with UID:12345@QWERTY" deletion is tried there will be a delete-vreply with UID:12345@QWERTY and a REQUEST-STATUS:5.x;No such entry! property in it.  Hence the CUA gets 2 delete-vreplys for the _same_ UID; one a success and one a failure.
2. If the  "VEVENT with UID:12345@QWERTY" deletion is tried there will be a delete-vreply with UID:12345@QWERTY and a REQUEST-STATUS:2.0;The events gone! property as well so the CUA can see that it was deleted.  So when the  "All VEVENTs last week" deletion is done next there would be no additional delete-vreply to send back since the VEVENT was already removed and thus not part of the "last week" set.  Hence the CUA gets 1 delete-vreply for the UID; one success and NO failures.

Thus ordering here can result in mixed
messages to the CUA.  

If the QUERYs did NOT overlap (as in
_your_ example) then there is no problem since there would be no duplication
of responses.  However when there is overlap we need to have a clear
and concise definition for how the processor is to proceed.

If the result sets are combined into
1 total set for processing instead of treated as separate actions (since
they came on the SAME command its NOT the same scneario as if they were
issued separately!) then we would get back 1 response per matching entry
(ie: VEVENT above) and there would be no confusion or ambiguity.

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