an idea as an alternative to stored queries

[Tim Hare <TimHare@xxxxxxxxxxx>]

This may have been thought of before, but what if we defined a _small_ set 
of commands for the most frequently used queries, documented how they would 
work in the protocol, and required them to be supported?

My proposals:

GET-TODAY: returns all VEVENTS, VTODOS, VJOURNAL entries for the current 
date, expands anything which recurs within the current day; i.e. a 
"snapshot" of the current days VCALENDAR entries.

GET-NEXT: returns next VEVENT whose beginning is after the current 
date/time (or, alternatively, a date/time can be passed and the next VEVENT 
after that will be returned). If a current date/time is within a VEVENT's 
DTSTART/DTEND range, how would we return that.

PUT-VJOURNAL: create a VJOURNAL event for the current date/time with the 
text passed.

There may of course be others, these three are those I would use myself off 
the top of my head.

I believe this solves the problem for small-footprint CUAs, with little 
memory, (if such devices still exist by the time we get CAP out <grin>) 
better than the stored queries method.  The CUA only needs to send the 
command - the variables, which in most cases are date or date/time values, 
are implicitly defined from the clock of the responding CUA/CS.  This also 
eliminates the issues of network traffic since the CUA doesn't have to send 
a command to find the query, retrieve that query, modify it, and then send 
it as a series of commands.  The CUA just has to send one of the commands, 
and the desired results are returned.

If this proposal is accepted, my belief is that we should concurrently drop 
the idea of stored queries as it now exists.

Tim Hare
Interested Bystander, Non-Inc.