Re: an idea as an alternative to stored queries

On Friday, November 21, 2003, at 04:22 AM, Tim Hare wrote:

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

Two things came to mind here.
1) The above 2 commands look like 'SNMP'.

2) I do not see a real advantage for both client and server.
    A) For a client you have to specify the current date and timezone.
       The timezone is needed to tell the server what dat he means in 
particular
       and must adjust it to the clients timezone. The server maybe in a 
different
       timezone.
    B) The server must translate this somehow into a query for a specific
       start and stop time. As a result, I believe the request is little
       easier on the client, but now more burden on a server.

Or am I missing something??


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

Can you elaborate?? Since I believe this is close to a CREATE and then
there is no benefit.

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

In general, I think it could be interesting to look at which
common request are mainly made, but I believe more strongly that
having 'generic' commands can serve a better purpose.

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

I would earlier believe that a mechanism to limit the amount of 
components
returned on a request woul help.

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

Why?? Just curious, not selecting a side.

regards,


Harrie