Re: [Fwd: Re: CAP-12-a: Stored queries still?]

[email protected]
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.