Re: Status of the CALSCH working group (QUERYID)

Doug replied on 11/07/2003 04:14:11 PM:
> > EXPAND and QUERYID -- I am having a hard time understanding how stored 

> > queries can be useful without search wildcards. Can anyone explain 
> > this to me? We dropped the ability to auto execute stored queries.
> 
> There is NO restriction that the results of fetching a stored query 
> return static results (the
>  same is true for all components) . So I could define (using unspecified 

> admin tools) a stored
> query called 'TODAY' that returns a dynamically returns a VQUERY when
> run returns the results of todays events from several calendars.

A: There were several questions regarding the usefulness and behaviour of 
stored queries so the WG (except for Doug) decided to defer the entire 
concept to post CAP 1.0 so they could be adequately addressed.

B: The original intent was to make it easier for 'thin' clients to do 
normal queries and save them bandwidth and memory footprints.  However we 
never actually had wildcarding in the language (or we lost it at some 
point) so we failed to fulfil the original intent.

C: Anyone can provide a stored VQUERY on their implementation (as an 
extension to CAP 1.0).  Any CUA should be able to retrieve it using CAP 
1.0 by simply SEARCHing for the QUERYID:TODAY and the CS should return it. 
 Unfortunately there is nothing in the CAP 1.0 spec that would be able to 
do this since "today" is a concept that is not encodable using the current 
query linga.  As such doing what Doug suggested results in a VQUERY that 
exists in the CS that can be referenced by using QUERYID but that is NOT 
retrievable by the CUA.  This means that the user has NO way to know what 
query "TODAY" is (and its worse if the CS is in a different TZ than the 
user so they can be in different days when the query is run!).  Plus, it 
is not safe for CUAs to assume or use canned 'special' queries that are 
not retrievable.  Product A's "TODAY" query may be different from Product 
B's "TODAY" so mixing CUAs and CSs could have incorrect results.

> When we had auto-execute, then you could run them without fetching
> them. Now you have to fetch them and then run them (I still do not see 
> why that is better).

You dont have to fetch them and then send them back, you simply craft them 
locally and send them.  Its also been demonstrated that the savings in 
octets is minimal (~50-60 I think) so making ALL CS's implement stored 
queries is something I find questionable.  Also, just how would someone 
using your CUA that wants to use the stored "TODAY" query work when 
talking with someone elses CS that does not support stored queries?  It 
would have to construct the query itself and the just send it to the CS.

Given the CAP 1.0 query language we have, the CUA must rewrite nearly all 
queries related to frequently performed operations (ie: What alarms 
trigger in the next 15 minutes? What entries are on my calendar for Today? 
etc) so what benefit there may be to stored queries is offset to the 
degree that the CUA has to rewrite the query and resave it.

> All of my requests for such an explanation have been ignored by those 
> that do not want
> the CS to be able to have builtin, stored, or dynamically created 
> queries. PDAs and
> devices on low bandwidth or high latency connections need this feature.

Unless all CUAs (thin and fat) have the same fixed list of stored queries 
that do things that are NOT representable in CAP-Query Language, there is 
little if any demonstratable savings in keeping stored queries for CAP 1.0 
as they were defined. 

You also neglect to factor in the need of the thin clients to have to 
rewrite stored queries to keep them accurate (ie: rewrite the bounds of 
the alarm TRIGGER check every 15 minutes). 

In addition I see no benefit in relying on remotely stored queries that 
are not currently encodable in our query language thus unrepresentable in 
response to this simple SEARCH:

      C: Content-Type: text/calendar
      C:
      C: BEGIN:VCALENDAR
      C: VERSION:2.0
      C: PRODID:-//someone's prodid
      C: CMD:SEARCH
      C: TARGET:relcal1
      C: BEGIN:VQUERY
      C: QUERY:SELECT * FROM VQUERY
      C:  WHERE QUERYID >= 'TODAY'
      C: END:VQUERY
      C: END:VCALENDAR

that are ~product specific and thus non-interoperable (or even in 
conflict).

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