[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CAP 10: CREATE Command and ordering of responses.
On Thu, Jan 30, 2003 at 02:41:24PM -0500, Bruce_Kahn@xxxxxxxxxxxxxxxx wrote:
> > 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
> > 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:
Sorry no, I thought I'd voiced my concern so many that it would be clear.
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.
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).
My reading of it was that it added a requirement for keeping results for
different QUERY separater (otherwise how could you possibly order them?)
And there's still a mention to ordering, which I'd like to get removed.
> There MUST BE one "VREPLY" component returned for each object that is
> deleted or marked for delete.
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 ;-)
> 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.
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?
> > 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?
> 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.
Aha! Now you're really seeing my point! Look it might be that I'm being
silly, but I really interpreted the above text as allowing, nah, mandating
that we return 2 copies if they are matched from separate queries.
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.
OK?
Bye,
Andrea
--
Andrea Campi mailto:a.campi@xxxxxxx
I.NET S.p.A. - BT Ignite http://www.inet.it
Technical Dept. - R&D phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy