Re: [Fwd: Re: CAP-12-a: Stored queries still?]

[email protected] wrote:
> 
> Doug replied on 09/03/2003 06:07:24 PM:
>  > > We never reached a clear concensus on the issue of stored queries in
>  > > CAP.  The thread just stopped in mid-January 2003 and I still question
>  > > the usefulness of them in CAP.
>  >
>  > Is what Bruce means, it it does not end until he agrees. There was
>  > a debate - two of them over the last two years.

> 
> Since there is no way for any client ('fat' or 'thin') to create a 
> stored query that is really beneficial and reusable

Your opinions presumes you speak for everyone, and you do not.
If you do not find them useful, then speak for yourself.

> I question the need 
> to have them as a mandatory CS feature.  The query language has NO way 
> for crafting a query thats reusable like "Find me the alarms that go off 
> in the next 15 minutes" or "What entries are on my calendar for today". 
>  Thats because we have no concept of being able to wildcards; the query 
> MUST use exact comparisons to _explicit_ values.  

You also have never proposed a solution to your need that you describe
above. Those that did propose a solution got the text in CAP. That
is the way it works.

> This hardly makes the stored querys reusable; the CUA will have to 
> update them with new _explicit_ values on some regular basis.

Explain how *ANY* of the queries I sent need to be updated on
a regular basis.

>  > Which is irrelevant as there ARE queries that can be saved
>  > without wild cards.
> 
> Yes there are; _any_ query can be stored.  However they do NOT fulfull 
> the original intent of the stored query feature nor does storing them in 
> the CS any strong benefit to anyone compared to the cost of implementation.

You can also store bogus VEVENTs that still fit the ABNF grammar,
So what's your point? Do you want to propose that we add text
saying "do not do something unless it is useful"?

>  >                      No place in CAP does it say that
>  > you must be able to do stored queries based on time or wild cards.
> 
> You are missing the point or trying to deflect it.

No, your missing the point, it was debated, added, text changed, and
no one saw that there was a need to add grammar to do the things that
you keep saying would make it useful. If you have a proposal - make it.

> The intent of stored queries was to make it easier for 'thin' clients to 
> keep smaller footprints by allowing them to not have to (re)craft 
> commonly used queries again and again; they relied on the CS to keep the 
> query and involk it when the CUA needed it.  This is a great concept but 
> we failed to design our query language to allow for it to be _actually_ 
> useful.

You keep (re)stating the obvious - however I find the queries useful
as did CS&T. So did John.

Currently a CS has to CREATE, MODIFY, MOVE, SEARCH, and DELETE
components. VQUERY is just another component. And QUERYID is a way
to say:

	Go SEARCH for a known component (a VQUERY) and store
         the results in in the CUA

	Now send that same component back to the CS and get
	the results and store in the CUA.

Your calculations (omitted) failed to calculate the fetching
of the same query that you then send back to the CS.

Looks beneficial and efficient to me to just say:

	Go to QUERYID and store the results in a the CUA

Remember Cell phones and PDAs do not have a user interface that allows
the user to customize the queries. It gives the PDA and Cell phone
companies the ability to modify the result sets.

Plus there is NO requirement that the contents of QUERYID be
static, they could be dynamic.	

> Until now noone has provided any kind of examples that show why we MUST 
> have this as part of ALL CS implemenations.  The CAP drafts make an 
> implicit requirement that CS implement stored queries and I think this 
> is wrong to do, especially given the lack of any demonstratable benefit.

Something was demonstrated you comment on it below.

> Now that you've finally got some examples, lets take a look at them to 
> see if they meet the original intent and compare any benefits to the 
> cost of saving queries...
> 
>  >    QUERYID:Common
>  >    SELECT VEVENT FROM VEGANDA WHERE STATE() = "UNPROCESSED"
>  >    SELECT VTODO FROM VEGANDA WHERE STATE() = "UNPROCESSED"
> 
> Yes, this is a common kind of query ("Find me 'new stuff'").  
> 
> However there is nothing complex here that would require any CUA ('fat' 
> or 'thin') to take up that much extra space or cycles to send.

It allows the Cell phone and PDA to have a GUI-CUA that runs on
a full computer to specify what you get back when you say 'Common'.
Such as VEVENT only, or VTODO only, or whatever. The PDA and
Cell phones are not going to have that ability.

Stored queries allows a 2nd-CUA to specify the query restrictions
for GUI-challanged CUAs.

And if you search the archives you will find that we specifically
stated at the time we were doing the requirements for iCAL that not
all CUAs will have a user interface. They can be hardware or software that
responds to data in the CS. Stored queries allows their search results
to be configured for them. If you also add the fact that the contents
of a stored query can change from time to time, plus the CUA-BOTs
that we talked about, you now have a fully configurable searches.

Not all CUA's are computer based GUIs with user interfaces and lots
of memory and processing power.

-- 

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

                 We Do Standards - You Need Standards