Re: What good are stored VQUERYs?

[Andrea Campi <a.campi@xxxxxxx>]

On Thursday, November 7, 2002, at 12:14 AM, Bruce_Kahn@xxxxxxxxxxxxxxxx wrote:
> but I have yet to see what use storing queries can be.  After all, I cannot 'wildcard' or macro expand anything in a query so I cannot create a stored query for "Find me all events on my calendar for today" or "What events have alarms that trigger in the next 15 minutes", etc.  Each VQUERY that a CUA sends to the CS needs to be custom built to have the right parameters (ie: dates/times).
>
> So in the interest of KISS I ask why a CS should (MUST?) store VQUERYs if they are effectively 'single shot' queries?
>
> Unless there is a common case that Im just not seeing I would like to propose that we remove the concept of stored queries entirely.

IMHO the best reason to KEEP stored query is precisely what you mention, that is, the absence of parameters.
Nowhere in the draft I see anything which implies stored queries MUST translate to CAL-QL; the way I interpret this is, a CS can implement them anyway it wishes.
Looking at your example, a CS could expose a stored query named "All events on my calendar for today", with no corresponding CAP-QL. When a CUA executes the query, the CS simply "does the right thing", and retrieves events for today.
It's true that this doesn't improve interoperability at all, but it allows matching CUA and CS to do very powerful queries with minimum effort.

Now, if we extended CAP-QL to allow parameters in stored query invocation, I'd be even happier. However, allowing the syntax now and building on it later on is better than nothing...

Bye,
Andrea