Re: an idea as an alternative to stored queries

>>
>>
>>> With a stored query, there is no hope of knowing what the query does.
>>
>>
>> Fetch it and look just like any other component.
>
>
> But part of the point of stored queries is that you're supposed to be 
> able to do things that can't be done in the query language.  (Right?) 
> Given that, there's nothing to fetch. 

No. A dynamically created query is not the same thing as an undefineable 
query.

Today a fetch of a hypthotecial 'CELL-VENDOR-NAME-TODAY' could
return  a VQUERY containing:

    ....where RECURRENCE-ID < 20031202T000000Z
         AND RECURRENCE-ID > 20031201T000000Z

Tomorrow a fetch of that same VQUERY could return
one containing:

    ....where RECURRENCE-ID < 20031203T000000Z
         AND RECURRENCE-ID > 20031202T000000Z

How that dynamically stored VQUERY is inserted into your calendar
and dynamically altered depending on the time/TZ is not a CAP issue,
it is an implementaiton issue.

> Besides, the only reliable strategy would be to fetch it every time 
> you connect; that's not going to save you anything over sending it 
> every time.

No.  If your cell phone needs 'get-vevents-only-for-today' and you tweak
that VQUERY and change the VEVENT to VJOURNAL's, then you
busted the query yourself, it is not a protocol issue, don't do that.

Cell phones do get me XXX queries now (not using CAP however) and the
cell phone can not change what is returned or tweak the contents of the
query and do not need to download the query each time.
Stored queries allow for cell phones to use CAP.

-- 

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