Subject: Re: CAP issues, Sections 1 and 2

From: "John Stracke" <[email-masked]>
Date: Mon, 25 Mar 2002 17:16:06 -0500

>> But how does that response represent a query such as "today's stuff", 
if 
>> it can't be expressed in the normal CAP syntax?
>
>Who cares? It is vendor specific.

I'm sorry, but that's a bad answer.  If we're going to include stored 
queries in CAP, we have to have cases in mind where they're useful without 
relying on proprietary extensions.  Otherwise, we can leave them out, and 
people who are inclined to get proprietary can add whole new 
commands--that's essentially what a proprietary stored query would be, 
after all.

>Such as get-all-booked
>VEVENTs

If you've got a CUA that doesn't want to spend the bandwidth to send the 
query inline, then you definitely don't want "all booked events"; you want 
"all booked events in this time range".  As things stand, that time range 
would have to be hard-coded in the query, which is pretty useless.

I see two viable paths: either we drop stored queries, or we add something 
like SYSDATE (and functions to parse out the year, month, etc.) to the 
query language.

Personally, I'd prefer to drop stored queries.  I really don't see the 
point, even for a PDA; the data that comes back is going to be potentially 
much larger than the query.

/================================================================\
|John Stracke                    |Principal Engineer             |
[email-masked]   |Incentive Systems, Inc.        |
|http://www.incentivesystems.com |My opinions are my own.        |
|================================================================|
|Using strong crypto on the Internet is like using an armored car|
|to transport money from someone living in a tent to someone     |
|living in a cardboard box.                                      |
\================================================================/

---

From: Doug Royer <[email-masked]>
Date: Mon, 25 Mar 2002 15:54:28 -0700

John Stracke wrote:

> I'm sorry, but that's a bad answer.

Okay fine, here is an answer for my private 'today' query:

	BEGIN:VCALENDAR
	VERSION:2.0
	METHOD:REPLY
	BEGIN:VQUERY
	QUERID:my private query
	QUERY:SELECT * FROM VEVENT where X-virtual-col = 'today'
	END:VQUERY
	END:VCALENDAR

Does that help? :-)

Now ANY CUA can query for it to see of they exits, and
ANY CUA can query for the details. I'll bet my CS returns an
empty set or permission denied when non-me-CUAs try to
find out what that query does and the contents of the stored value.
I can think of several other canned queries that I use.

However your CUA would still be free to store queries in my CS.
And my CS will not care what they do as long as
they are CAP and iCalendar compliant objects and you otherwise
have permission.