Re: Status of the CALSCH working group (QUERYID)

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

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: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration            
    Phone: 978.399.6496
IBM Software Group                
        FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...