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

Doug wondered on 09/04/2003 03:47:59 PM:
> > For those frequently used querys like "What events are on my calendar 
> > for XXX" or "What alarms trigger in the next 15 minutes" the CUA 
simply 
> > does a Cscanf() of the correct inputs (XXX or the current date/time) 
> > into a loaded query and then sends it.   Again, there is no 2 trips 
> > across the wire for the query.
> 
> NO ONE has proposed such a thing - who cares?

You have when you keep saying "2 trips on the wire" (paraphrased). However 
I think you are misunderstanding something here: removing stored queries 
entirely means the CUA wont try to use them (trip 1), fail and then craft 
its own query (trip 2).  The CUA simply crafts the query and sends it (1 
trip).

> > 1: Failure to find a particular QUERYID in a given TARGET,
> 
> Why do you feel that would be any different to a query for a UID
> that did not exist? Its the component-ID tag. No such distinction
> exists.

Because there is a definite difference between "I cant find the query you 
wanted me to use to find those VEVENTS" and "I cant find those VEVENTS". 
Both are errors but dealing with them is different.  See the difference 
now?

> > 2: The ability to specify multiple TARGETs in a VQUERY (ie: Do ALL 
> > TARGETs have to have the QUERYID in it or just one or is it something 
> > else?)
> 
> Not sure which TARGET you mean:

Clearly not (or is this another tactic?).  In a VQUERY there can be one 
(or multiple) TARGET properties to tell the CS where to go look for the 
QUERYID (go recheck the ABNF in 9.6 if not with me still)

It is unspecified how a CS deals with finding/selecting/using the QUERYID 
in multiple TARGETs (those TARGETs you can put inside the VQUERY, not out 
side it at the command level).  Does it use the first one it finds only? 
All of them? All the CU has access to? Does any failure to find the 
QUERYID in any/all/some TARGET mean the command should be rejected or 
attempted anyway? Etc...

> > 3: How are failures to find/use the QUERYID distinguishded from other 
> > command failures (ie: The SEARCH failed because you cant see/find/use 
> > the QUERYID in a TARGET vs the SEARCH failed because you cant access 
the 
> > TARGET vs the SEARCH failed because you only can read stored queries 
but 
> > not other data in a TARGET vs...?)
> 
> As you can send the EXACT same query manually, why do you feel that
> it would be any different?

You really do not understand some of this stuff, or at least are trying to 
appear not to.  Ill give you the benefit of the doubt and say that it was 
not clearly phrased on my part.

In the stored query case the CUA is expecting the CS to do some kind of 
query lookup internally (based on QUERYIDs and TARGETs), use that to find 
the proper data set for the command to work on and return the results.

In the CUA query generated case, the CUA does not expect the CS to have to 
go find and them craft some query to use for the command; it generates the 
exact query it wanted to use.  There is no needing for the CS to go get 
the query or parts of it from any other place in the CS so there are no 
problems like VCARs or non-existant QUERYIDs.

In the former case there is potential for the CS to fail to find/craft the 
query that the CUA was expecting since there are things like VCARs, etc 
that now come into play for getting the query data separate from the data 
set the query is to work on.  As such, the the CUA may not get the same 
results they expect because the effective query used by the CS may not be 
exactly what they intended.

Couple with this the fact that there is no way for the CUA to distinguish 
between "I was unable to craft the query you requested to perform the 
command you sent" from "I was unable perform the command you sent' (see 
top) then it should be clear now that there is added complexity in using 
or relying on stored queries that is not currently clearly described in 
CAP.

> All of your assertions above are unfounded and unsubstantiated.

If you stil think so then perhaps we need to get an someone here who sees 
the difference described above and can see the issues when they are 
presented.

>                             They have nothing to do with the text in 
CAP.

Err, part of the issue is precisely that: there is NO text in CAP to deal 
with these things.  This is yet another reason why stored queries need to 
be removed.  All aspects of their use has not been fully designed or dealt 
with in CAP.

> Those problems do not exist in any way that is different from non-stored
> queries.

Actually they do not.  Go recheck the part related to issue 3 again...

So, my proposal is still on the table: We remove all references to stored 
queries in CAP 1.0 and defer them to a followon draft when they can be 
properly designed to meet our original intent.

So far the only disagreement on this proposal is yours.  Anyone else?

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email protected]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...