Re: an idea as an alternative to stored queries

Tim Hare wrote:

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

The CUA timezone is passed down in the CUA capability reply. Lets just 
use that.

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

Part of the merging of ideas over the last few years (and note that 
stored queries have
been in CAP since it inception and in -00 of CAP). Included compromises. 
One of those
compromises was stored queries. As with any component the CS can have 
VCARs that
do no permit them to stored. But the conversations were to allow them exist.

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

Predefining what they are is not the same issue as defining that
they can exist.

Some enterprise vendors do not want them because they are not
concerted with bandwidth. PDA and CELL vendors will do them anyway
because they (or their customer) has to pay $$$ for air time
if they do not exist. So the compromise was that we would
define how to store them. And again, a CS is free to VCAR
them to permission denied for a specific implementation
as one could do for any other component.

What user/vendor-A wants back may not be the same as what
user/vendor-B's cell phone is even capable of handling.
A might not be able to handle VJOURNAL - so why pay
for the bandwidth to transfer them.

They do not need to be predefined. Just a standard way for
them to be stored so that when vendor-C does a query all from
VAGENDA they will know what it is and if it can ignore them.

It is not as if a CS is going to allow all random CUAs
to deposit stored queries in any random calendar within
its store any more than the CS would allow a random CUA
to deposit booked entries in any random calendar.

We concluded during the original debates that trying
to predefine the exact query in advance was not going
to work as that depended on the target CUA and its target
customers. So we agreed that they could be stored and that
as VCAR's would limit them to the owner, they would be known
to the owners CUA(s), no mysterious object types to guess
at by non-same-vendor CUA's as they all would be the
same component type (VQUERY) . Ether the CUA knew what XXX
did or not. Ether you were allowed (by VCAR like any other
component) to modify it, remove it, add one, or not.

--
Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email protected]                 | Office: (208)520-4044
http://Royer.com/People/Doug   |    Fax: (866)594-8574
                               |   Cell: (208)520-4044

               We Do Standards - You Need Standards