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

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Andrea wrote on 01/29/2003 12:06:00 PM:
> So basically, there's no need for ordering anywhere, right? I'm
> all for removing the requirement then.

Anyone not agree??

> But let me insist: we need to clarify how should
multiple VQUERY
> (or multiple QUERY properties) behave. 

A very good idea but I thought it was
covered (in the non-overlapping cases) in Subsections 6.1.1.[15-18].  Although
as I revisit this area I see that no text clearly indicates the kind for
responses that would be generated for the example querys.  I could
guess at the responses given the text under the DELETE command (see next
bits).

>              
                     
    There is more to this than
> SEARCH, since VQUERY are used all over. In addition to the basic
> question (that I think I've asked many times), there's the issue
> of the same component matching more than once.

There is text for the DELETE command
already and I think thats what you had in mind at one point:

There MUST BE one "VREPLY" component returned
for each object that is deleted or marked for delete. 

So if Im deleting multiple VEVENTs or
VTODOs then I should get back 1 delete-vreply per deleted entry.  They
can be in all in 1 delete-reply OR in any number of delete-replys (as long
as there is at least 1 delete-vreply in each delete-reply).  

I havent spent a lot of cycles on it
but why can't this apply to all commands too?  A spot check of a couple
other commands reveals no similar text for them.  Perhaps thats what
we need...

> Example:
> 
> BEGIN:VCOMPONENT
> CMD:DELETE
> BEGIN:VQUERY
> QUERY:SELECT * FROM VEVENT WHERE DTSTART > '20030101'
> END:VQUERY
> BEGIN:VQUERY
> QUERY:SELECT * FROM VEVENT WHERE LOCATION = 'Milan, Italy'
> END:VQUERY
> END:VCOMPONENT

Ok, this effectively does 2 sets of
DELETEs in 1 transaction.  Not sure that this is a normal CU action
but its possible (though I am curious to see what UI can manage this cleanly)
given our current design.  The design also permits 2 VQUERYs that
select from different components (ie: the 1st is VEVENT and the 2nd could
be for VTODOs).  What a tangled web we weave...

> Should this return:
> 
> 1 - all results for both in one VREPLY

Not cool.  There should not be
2 UID properties in a single VREPLY component.  This also violates
the cited text above.

> 2 - one VREPLY per query

Better in that no duplicate UIDs happen.
  It also violates the cited text above.

> 3 - one VCALENDAR per query

Overload...  Ugh!

> 4 - undefined

Not cool either.

What happend to just getting back 1
delete-vreply (VREPLY) per matching entry?  These VREPLYs can be in
any number of VCALENDARsn as long as there is at least 1 VREPLY  per
VCALENDAR.  This does NOT preclude sending back ALL the VREPLYs in
1 VCALENDAR.  There is also nothing in the draft that prevents sending
back 1 VREPLY per VCALENDAR and sending back 1 per matching entry.  Recheck
the ABNF for delete-reply.

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

One could say that its dependent on
the internal CS design on how operations are sequenced.  If the deletes
happened serially then there is no way for the 2nd to 'reDELETE' a match
from the first set is there?  If they happen concurrently then its
possible that you'd get back 2 VREPLYs that indicate deletion (unless you
actually semaphored your container pool so that you dont get contention
issues!!  Hint, hint...).  However concurrent operations on the
same data set can be dangerous (esp. if the operations are different like
DELETE and MODIFY) so Id guess that most CS implementations would serialize
them.  Still, its kinda dumb in my mind to indicate that something
got deleted twice (or more really) by a single command...

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?

Try changing the command to be a another
command like, say, SEARCH and see if the logic still holds.  The CUA
asked for VEVENTs that match a couple sets of criteria.  Would it
make any sense to return 2 copies of the same VEVENT??  I dont think
so.

> That's my main reason for choosing #1. 

I dont like your #1 because it does
not conform to current practices of a single UID per component.  
Besides, your #1 does not address the "issue
of the same component matching more than once."

>              
                     
    After all, if we wanted to
> separate the answers, we wouldn't send them in one query, right?

I still wonder how realistic this example
is but it is possible...

I think that if we restrict the XXX-reply
responses to be per unique matching entity no matter the command then that
should answer your questions.

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