Re: an idea as an alternative to stored queries

Not knowing SNMP that well, I'm not going to address your item 1) - I can't 
tell if it's a good or bad thing to look like SNMP.

As to 2) - the advantage to the client is the ability to have simple 
commands which are understood at the server, instead of building a 
complicated query or going through a complicated retrieval  and 
modification of a stored query, and in these two cases the client does not 
need to build DTSTART/DTEND information into a "query" since it's implicit 
in the definition of the command.

The timezone issue does need to be handled, however it's probably pretty 
easy: In my opinion if the client sends its current timezone along with the 
date on the GET-TODAY command (or the date/time of the GET-NEXT command), 
the server should return the responses translated to that timezone if 
necessary. If the client sends no timezone, the server should send whatever 
timezone is in the component. Also, if no date or date/time value is sent, 
the server should use its local clock to supply those values.

Also you are correct that my PUT-JOURNAL command is basically the same as 
CREATE with a VJOURNAL event, so PUT-JOURNAL is not necessary.

The reason I suggested dropping stored queries was because we never reached 
consensus, that I can tell, about how such items would be implemented; my 
suggestion was to provide some of the function that stored queries were 
supposed to provide in a simpler manner that would allow the CAP draft to 
be finished; stored queries can always be designed and included in a future 
revision to the protocol if people feel the work is worth it.

Limiting the amount of components on a request isn't necessarily good, 
because you might not get the components you want and then you'd have to 
have a way to generate a query which said "give me everything from *here* 
onward", send that, see if you got the right stuff, etcetera. This could be 
a network traffic and response time problem. The two alternatives I propose 
involve one request and one reply; the scope of the command limits the 
components _somewhat_  in the GET-TODAY command (how many components could 
there be for "today" in most use cases?) and to _one_ VEVENT in the 
GET-NEXT command. This would allow faster response and lower network load.

I have, as yet, been unable to think of other commands that would be as 
useful, or as commonly used. If anyone else has good ones to propose, I do 
believe that they should be the types of commands that are short and quick 
like to two above, with minimal  client modification required. The most 
basic use case I can think of is a device with programming in ROM whose 
function is to download today's information and display it - the entire 
function, in CAP, would be ROMable using the GET-TODAY command with no 
timezone and no date passed, yet it could still retrieve the up-to-date 
information.

Tim Hare
Interested Bystander, Non-Inc.

At 03:03 PM 11/25/03 +0100, you wrote:


>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