Doug replied: > As we are not doing transactions there can not be more than > one match in your example provided. Once it is deleted by the 1st QUERY > it could not have existed for the 2nd QUERY to match. (no matter > which one of them you process 1st).
As Andrea has pointed out, this is not actually stated in the text and so he inferred that it was possible. I think we all here agree but its just not clear in the draft.
5. When multiple "QUERY" properties are supplied in a single
"VQUERY" component, the results returned are the same as the
results returned for multiple "VQUERY" components having each a
single "QUERY" property and the results are return in the same
order as the "VQUERY" properties were specified in the original
command.Except for the fact we are removing 'ordering' (Sorry I missed its removal in this section), if you were to submit two VQUERIES each with a single QUERY the second would not be able to delete the object the 1st VQUERY had deleted.
> For QUERYs that are not deletes I would say return each VREPLY > that matches the supplied QUERY value.
Whats the use of this? If the VEVENT matches any QUERY then it should be sent back; do multiple copies give it any greater emphasis to the user? Would resending the same large ZIP ATTACHment result in anything more than just extra wasted bandwidth?
It had to do with if you were to submit two VQUERIES each with a single QUERY the second could return the same entries as the first.
The only justification I could see for sending mulitple XXX-replys was due to different SELECT clauses that may or may not overlap. That is, 1 VQUERY asks for ATTENDEEs and another asks for ATTACHments and VALARMs. However I have to question the Real World usage of this kind of overlapping selection. Yes, its legal to do in CAP (hence why Doug wants it?)
Please don't personalize the issues - this was put in after some objected to multiple QUERYs in a VQUERY. They did not want to be forced to do optimization in the CS.
_single_ SEARCH command for "All EVENTs on my calendar for Today" AND "The EVENT whose UID is 12345@xxxxxxxxxxxx" all the while asking for different sets of properties from each query?? Each of these are really much much more typical as separate actions on the CUs part.
Id like to take a simplified approach here since I see no real benefit to over engineering this.
At no place in the draft are you required to put multiple QUERYs in a single VQUERY. The simple approach could be to issue multiple VQUERYs and that can also return the items multiple times.
The reason multiple QUERYs were added was so that you could get all BOOKED entries for a date range and all UNPROCESSED entries in one round trip. ~Something~ like:
QUERY:SELECT * FROM VAGENDA WHERE <...date range...>
AND STATE() == 'BOOKED'
QUERY:SELECT * FROM VAGENDA WHERE STATE == 'UNPROCESSED'It avoided two round trips for what was thought to be a common 1st query after authentication.
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@xxxxxxxxx | Office: (208)612-INET
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature