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

From: [email-masked]
Date: Tue, 18 Feb 2003 17:43:05 -0500

Andrea wrote on 01/31/2003 03:02:58 AM:

Sorry, I was out w/the flu all last week so Im playing catchup again...

> This is the text I have in mind:
> 
>    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.

I like this.  The ordering mandate from the original text was unhelpful 
IMHO.  After all, for the modified example:

BEGIN:VQUERY
EXPAND:TRUE
QUERY:SELECT * FROM VEVENT
WHERE RECURRENCE-ID >= '20000801T000000Z'
AND RECURRENCE-ID <= '20000831T235959Z'
AND STATE() = 'BOOKED'
QUERY:SELECT * FROM TODO
WHERE RECURRENCE-ID >= '20000801T000000Z'
AND RECURRENCE-ID <= '20000831T235959Z'
AND STATE() = 'BOOKED'
END:VQUERY

just what good is it really to the CUA?  As long as all the VEVENTs and 
VTODOs are returned, no matter the order, then life is good.

> Right now, I have no idea what:
> 
>                            the results returned are the same as the
>        results returned for multiple "VQUERY" components having each a
>        single "QUERY" property
> 
> because we haven't defined that yet (or agreed upon it, for that 
matter).

This simply means (to me at least) that the delete-replys for:

BEGIN:VQUERY
QUERY:SELECT * FROM VTODO WHERE UID = 'uid123'
QUERY:SELECT * FROM VEVENT WHERE UID = 'uid123'
END:VQUERY

would match the delete-replys for:

BEGIN:VQUERY
QUERY:SELECT * FROM VTODO WHERE UID = 'uid123'
END:VQUERY
BEGIN:VQUERY
QUERY:SELECT * FROM VEVENT WHERE UID = 'uid123'
END:VQUERY

and for:

BEGIN:VQUERY
QUERY:SELECT * FROM VEVENT WHERE UID = 'uid123'
END:VQUERY
BEGIN:VQUERY
QUERY:SELECT * FROM VTODO WHERE UID = 'uid123'
END:VQUERY

Im NOT saying that they would be a octet for octet match; they would be a 
logical match in that the ordering could be different. Sound correct?

> My reading of it was that it added a requirement for keeping results for
> different QUERY separater (otherwise how could you possibly order them?)

The short citation you included has no mention of ordering so that would 
not be true.   "The results returned" are the delete-reply(s) in the ABNF.

So now Im questioning the usefulness of this "either or" design philosphy. 
 From Section 6.1.1:

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. 

Since a VQUERY can have multiple QUERYs in it and I can have multiple 
VQUERYs as well, why do we need to have both??  Why cant we just have 1 
VQUERY that has multiple QUERY properties in it and call that good? 

This would simplify the design.  Hmm, perhaps there is just a reason that 
we need to have both forms that Im just forgetting...

> And there's still a mention to ordering, which I'd like to get removed.

Agreed.

> Uhm yes sorry I overlooked that (maybe because SEARCH doesn't behave 
like
> that: all commands return one match per VREPLY, apart from SEARCH where
> it's not clear); but I think I got it right in the code ;-)

Please point out the unclearness in the draft so we can fix that!  Clarity 
good, uncertainty bad!!

> I think we agree then. So what about we change the text I quoted to:
> 
>    5.  When multiple "QUERY" properties are supplied in a single
>        "VQUERY" component, the results are returned just like they
>        were matches for a single "VQUERY" component having a single
>        "QUERY" property.
>        When multiple "VQUERY" componentns are supplied, the results
>        are returned just like they were matches for a single "VQUERY"
>        component having a single "QUERY" property.
> 
> Is that fine with you?

I agree. 

Before we go on Id like an answer to my question above.  If we do not need 
to have both multiple VQUERYs (with single or multiple QUERY properties) 
AND single VQUERYs with single or multiple QUERY properties then lets 
simplify the design even more.

> > > Now what happens if the query matched the same component? Do we
> > > return it in both replies or in one (which one)?
> > 
> > IMHO: The responses should (MUST?) be per unique matching entity. 
> [...]
> > My preference is that we get back 1 XXX-reply per unique affected 
> > component so 1 delete-vreply per UID in the case of of the DELETE 
command 
> > no matter how many VQUERYs or QUERYs match it. 
> > 
> > I have a mild aversion to the idea of returning multiple 
delete-vreplys 
> > per matching entity because it serves no purpose to tell the CUA "I 
> > deleted the VEVENT with UID:EVENT1.  Oh yeah, I deleted the VEVENT 
with 
> > UID:EVENT1 (again)."  Does it serve any real purpose?  You really cant 

> > doubly delete it can you?
> 
> I agree. Now can you show me where in the text is that stated?

There is no text to the effect I stated.  I said "My preference...".  Its 
yours too.  So far I dont hear disagreement either so we should put in 
some explicit text to this effect so noone else has to assume/guess it. 

I propose inserting at the right place under Section 10. Commands and 
Responses (Doug's choice) something like:

    Responses for a given command MUST be per unique matching entity. That 
is,
    a command effects an entity only than once per command no matter the 
number
    of times the entity matches the QUERY properties in used to select the
    entity.  For example, if a DELETE command used two separate QUERY 
properties
    to delete all VEVENTs for last week AND the VEVENT whose UID property 
was
    "[email-masked]" and that VEVENT occured last week then only one
    delete-reply for that VEVENT MUST be returned.

Not all commands need such prose (ie: GENERATE-UID or GET-CAPABILITY), 
only those that use VQUERYs in them.  I just didnt quite know how to best 
phrase that but Im sure Doug can fix that up.

> So just to make sure we agree. From a high level point of view, we 
basically:
>  - for each TARGET:
>    - merge all results from all the QUERYs, keeping only 1 copy of each
>    - if CMD != SEARCH act on them
>    - send them back. SEARCH defines the order in which we need to send 
results
>      back, the other commands return results in undefined order.

Yup, we agree pretty much. 

Im not sold on 1 tiny bit though: Why does SEARCH need to be special 
cased?  If I do the EXACT same VQUERY for SEARCH that I do for DELETE (see 
prose above), I would expect to only get back 1 copy of the VEVENT in a 
XXX-reply.  I dont see any need to isolate SEARCH from the rest; the 
results should always be unique and unordered...  (Just how many times 
would you want to suck that 5M ZIP down over a dialup link if you matched 
4 times on one SEARCH??)

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