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

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

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
    "12345678@xxxxxxxxxx" 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: 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...