Re: [Fwd: Re: CAP-12-a: Stored queries still?]
| Newsgroups | gmane.ietf.calendar |
|---|---|
| Message-ID | <OFD68CB3EB.F97F2E1B-ON85256D97.0065BAC5-85256D97.0067B711@notesdev.ibm.com> |
Doug claimed on 09/04/2003 11:58:33 AM: > > The original intent was to provide a means for clients to save on space > > and cycles by not having to recraft commonly used queries and resend > > them. > > And it does save both bandwidth and octets especially when you consider > the 2 sets of QUERY/FETCH required without them. Err, I think you are mistaken in how non-stored queries work. The CUA does NOT first retrieve them from the CS (1 trip on the wire) and then resend them to CS in a command (1 trip on the wire). The CUA simply crafts the query locally using whatever inputs it needs/has and sends it. Just the 1 trip I described, not the 2 you seem to think. For those frequently used querys like "What events are on my calendar for XXX" or "What alarms trigger in the next 15 minutes" the CUA simply does a Cscanf() of the correct inputs (XXX or the current date/time) into a loaded query and then sends it. Again, there is no 2 trips across the wire for the query. Even for the stored query case, unless you count the initial storage case, there is only 1 trip across the wire for the query. Subsequent uses simply send QUERYID:Foo in the command and the CS goes to find it and then uses it (assuming it can find it and the CU has the ability to read it). There are undiscussed issues related to stored queries such as: 1: Failure to find a particular QUERYID in a given TARGET, 2: The ability to specify multiple TARGETs in a VQUERY (ie: Do ALL TARGETs have to have the QUERYID in it or just one or is it something else?) 3: How are failures to find/use the QUERYID distinguishded from other command failures (ie: The SEARCH failed because you cant see/find/use the QUERYID in a TARGET vs the SEARCH failed because you cant access the TARGET vs the SEARCH failed because you only can read stored queries but not other data in a TARGET vs...?) All of these undiscussed issues contribute to the proposal that we pull stored queries from CAP 1.0 and defer it to a later draft when they can all be covered. Especially since the feature as it currently exists does not fulfill our original intent. > Complaining without submitting a proposal is something > that almost never works. Likewise, rehashing an issue whose overwhelming data is against you wont change things. > If you want to have the ability to say > get me the alarms over the next 10 minutes - submit a proposal, > else - there is nothing to add. Perhaps you should read the acutal postings before you just fire back responses. Since you keep overlooking it perhaps Ill just make that the body of all repsonses from now on out until you see it (I dont hold my breath for accepting it). In the mean time, I repropose that all references to stored queries be removed from CAP 1.0 and the feature be left for a followon draft when it can be accurately and properly done. Bruce =========================================================================== Bruce Kahn INet: [email protected] Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... Warning: Dates in Calendar are closer than they appear.