[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CAP 10: CREATE Command and ordering of responses.
Doug said on 02/21/2003 04:55:58 PM:
> If you issue a DELETE with:
>
> QUERY:SELECT * FROM VAGENDA WHERE SUMMARY = 'ABC';
>
> Both UID 1 and UID 2 get deleted - agree?
Yup.
> If you were instead had issued as SEPARATE commands:
>
> QUERY:SELECT * FROM VAGENDA WHERE SUMMARY LIKE
'A%'
>
> Then later:
> QUERY:SELECT * FROM VAGENDA WHERE SUMMARY LIKE
'%C'
>
> The 1st query would have deleted both.
> The 2nd query would have not deleted anything.
[Snip]
> Do you agree?
Yes.
The first query would result in 2 delete-vreplys
being sent back; both with REQUEST-STATUS;2.0 on them and each with the
proper UIDs.
The second query would result in 1 delete-vreply
being sent back; most likely with a REQUEST-STATUS;4.x;No matches found
and NO UIDs. Actually I think it is NOT currently doable given the
current DELETE ABNF in the 17Feb2003 Draft:
delete-reply = "BEGIN"
":" "VCALENDAR" CRLF
calprops
; MUST include 'reply-cmd'
1*(delete-vreply)
"END"
":" "VCALENDAR" CRLF
delete-vreply = "BEGIN" ":" "VREPLY"
CRLF
deleted-id
request-status
"END"
":" "VREPLY" CRLF
; Where the id
is appropriate for the
; type of object
deleted:
;
; VAGENDA = calid
; VCAR = carid
; VEVENT, VFREEBUSY,
VJOURNAL, VTODO = uid
; VQUERY = queryid
; ALARM = sequence
; VTIMEZONE = tzid
; x-component =
x-id
; An instance =
uid recurid
;
deleted-id = ( calid / carid / uid / uid recurid
/ queryid / tzid / sequence
/ x-id )
As you will note, the deleted-id MUST
be in the delete-vreply but there are NONE to return in the case where
none match. So I think we found a flaw in the ABNF. The ABNF
needs to be amended so that its permissable to return a REQUEST-STATUS
but NO deleted-id for those cases where none match!! Better add this
to the CAP issues list before we forget it.
The above was done on separate DELETE
commands. The ordering of querys in the SAME command would probably
have the same results.
However you did not address my cases
where it can be shown that the ordering of the querys in the SAME command
WILL generate different and conflicting results.
Your cases are generic enough because
they deal with pools of entries rather than pools and specific entries.
My example of "All events last week" and "VEVENT with
UID:12345@QWERTY" is 100% legal and it deals with the case where the
2nd querys delete-vreply WOULD have a UID on it to match it to my QUERYs
SELECT information.
For this kind of case we can potentially
get mulitple delete-vreplys for the same UID in the _SAME_ command
with _different_ REQUEST-STATUSs. So what is the CUA to make
of that??
This is why I think we need to simplify
the approach as I already described. That way we do not generate
potentially conflicting information on the SAME command.
Lets revisit my case of the "All
VEVENTS last week" AND "VEVENT with UID:12345@QWERTY" to
also look at the separate command case too.
First, the ordering here can and will
produce DIFFERENT results in a single 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.
Right?
If the 2 were done in separate DELETE
commands the results would be as follows:
If the "All VEVENTs last week"
deletion is done first , there will be a delete-vreply with UID:12345@QWERTY
in it and a "REQUEST-STATUS:2.0;The events gone!" property so
the CUA can see that it was deleted. Then if the CUA decided to
ignore the fact that it just got a delete-vreply for UID:12345@QWERTY
it could just blindly try to expressly DELETE it. For that separate
DELETE command it would get back a separate delete-verply with UID:12345@QWERTY
and a REQUEST-STATUS:5.x;No such entry! property in it. As such it
got back 2.0 on one attempt and 5.x on another; NO conflicting information
really (just a dumb CUA to try and reDELETE something it was just told
was DELETEd!
If the "VEVENT with UID:12345@QWERTY"
deletion is done first there will be a delete-vreply with UID:12345@QWERTY
and a REQUEST-STATUS:2.0;The events gone! property so the CUA can see that
it was deleted. When the "All VEVENTs last week"
deletion is tried later there would be no delete-vreply with UID:12345@QWERTY
in it since the VEVENT was already removed. The CUA again does NOT
percieve a conflict as it did not get back a "Could not DELETE UID:12345@QWERTY"
response in the latter case as it was not there to delete nor would there
be any way to SELECT it from the pool of existing VEVENTs.
So by looking at the cases of sequencing
of multiple QUERYs within a _single_ it can be demonstrated that ordering
WILL result in conflicting result information in some cases when done on
the SAME command.
Did I miss anything that would make
my example analysis wrong?
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...