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

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Doug replied on 02/18/2003 08:28:09 PM:
> >  > 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.
> 
> 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.

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.

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

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.

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

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.

> Please don't personalize the issues - this was
put in after
> some objected to multiple QUERYs in a VQUERY. 

Sorry, not trying to get nasty or anything.


>              
                     
           They did not want
> to be forced to do optimization in the CS.

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

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

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.

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

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