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

From: [email-masked]
Date: Tue, 18 Feb 2003 18:03:14 -0500

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.

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

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?) BUT realistically speaking how many CUs are going to do a _single_ 
SEARCH command for "All EVENTs on my calendar for Today" AND "The EVENT 
whose UID is [email-masked]" 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. 

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Tue, 18 Feb 2003 18:28:09 -0700

[email-masked] wrote:
> 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.

Sure it is:

    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.

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

 >  BUT realistically speaking how many CUs are going to do a
> _single_ SEARCH command for "All EVENTs on my calendar for Today" AND 
> "The EVENT whose UID is [email-masked]" 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
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: [email-masked]
Date: Thu, 20 Feb 2003 17:56:20 -0500

>         order as the "VQUERY" properties were specified in the original

Hmm, sorry but I dont see any prose in the paragraph above that matches 
what you said in the 1st quoted block above.  The paragraph strictly above 
talks about "the same" results being returned no matter the order of 
VQUERY/QUERY pairings used.  There is nothing saying that results are 
unique per match that I see...

Put another way, that paragraph does not cover the case where the 
VQUERY/QUERYs overlap in their data sets.  What Andrea and I (and you I 
think) expect is that results are unique per matching entry, not mulitple 
per any VQUERY/QUERY combinations.

> QUERY the second would not be able to delete the object the 1st VQUERY

Common sense would dictate this but in the past Ive seen some folks a bit 
less than full of it when interpreting the RFCs. 

Its not clear in any text Ive seen that the actions based on mulitple 
VQUERY/QUERYs occur in any particular order or as an amalgum in one big 
operation.  If I were to combine the "All VEVENTs on my calendar for last 
week" and "VEVENT with UID:12345@qwerty" in a single DELETE command then 
it is not clear what kind of response(s) would get back when the results 
form an overlapping case.  (That is, UID:12345@qwerty occurred last week.)

For example, if the "All VEVENTS" were deleted first with the proper 
VREPLYs sent back then one _could_ assume that the "VEVENT with 
UID:12345@qwerty" would return a failure VREPLY.  However since there 
would already have been a success VREPLY for the first QUERY bit the CUA 
gets mixed messages. 

If however the CS performs the "VEVENT with UID:12345@qwerty" deletion 
first and sends back a success VREPLY and then it performs the "All 
VEVENTS" deletion then no such conflicting VREPLY would be sent back as 
the entry would have already been removed from consideration.

So ordering of the actions seems to have some implicit effect on the 
expectations.  This is why Andrea and I think that a unique response per 
entry is the proper course to take and the draft should expressly, not 
implicitly, define this.  If that means that we have prose that says "Only 
a single VREPLY MAY be sent per command per unique entity; mulitple 
VREPLYs per unique entity MUST NOT be sent per each individual command." 
then so be it.  Perhaps we need to put in some prose to the effect: "No 
matter the number or combination of VQUERYs and QUERYs, the entire 
combined result set is acted upon by the command as a whole." so that the 
proper net effect is acheived and its up to implementors to do it their 
own private ways.

> QUERY the second could return the same entries as the first.

Not what I was trying to ask.  Put another way: If my first QUERY SELECTed 
a different or overlapping set of properties to return than my second 
QUERY would/should I send back 2 different copies of the same entity?  Use 
the 2 QUERYs from above but add different and possibly partially or 
non-overlapping cap-val values.

Is it reasonable to actually send back 2 copies of the same VEVENT (thus 
possibly wasting the bandwidth) or should the CS send back one amalgumated 
VEVENT with all the matching requested properties and parameters?  I tend 
to prefer the latter over the former.  This may be the approach that would 
happen if we adopt the "Pool all the matching entries in the QUERYs into 1 
result pool and then send back 1 entry per uniqueue entry.", just that the 
CS would have to merge the SELECTed properties in this case.

> some objected to multiple QUERYs in a VQUERY. 

Sorry, not trying to get nasty or anything. 

>                                                They did not want

Not sure I follow a bit here. 

There is no optimization being done (or mandated) at all if the CS is 
expected to treat multiple VQUERY/QUERYs in any combination as all 
identical.  The only possible optimization I see is the "return in the 
same order" clause that we want removed.  The current text would allow a 
CS to just process queries on a first come, first processed basis thus 
allowing someone to craft a very simple CS quite quickly.  It however does 
not benefit anyone really as the results of this are NOT identical if the 
ordering of the queries is changed (see above DELETE example). 

I dont view making the proposed changes Andrea/I made as forcing folks to 
optimize their CS; I view it as good design.  Since some folks here are 
gung-ho to build their CS on robust RDBMS systems then our changes should 
make no great burden on them.  Even my "pool the result set" idea above is 
no great burden for them...

> VQUERYs and that can also return the items multiple times.

How is having 2 VQUERYs with 1 QUERY each simpler than 1 VQUERY with 2 
QUERYs in it?  Is it any more efficient to do so?  Its certainly more 
octets on the wire to achieve the _exact_ same results.

> a common 1st query after authentication.

If I can craft the EXACT same logical query using:

BEGIN:VQUERY
QUERY:SELECT * FROM VAGENDA WHERE <...date range...> AND STATE() == 
'BOOKED'
END:VQUERY
BEGIN:VQUERY
QUERY:SELECT * FROM VAGENDA WHERE STATE == 'UNPROCESSED'
END:VQUERY

with no apparent justification for this then I call this overengineering 
it.   Lets simplify the design to avoid "Well I did it this way only since 
the spec says I can.  I dont care if you only designed your product to do 
it only another way! kinds of discussions we will eventually run into 
otherwise.

Bruce