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

[email protected] wrote:
> 
> Doug claimed on 09/04/2003 11:58:33 AM:
>  > > The original intent was to provide a means for clients to save on 
> space
>  > > and cycles by not having to recraft commonly used queries and resend
>  > > them.
>  >
>  > And it does save both bandwidth and octets especially when you consider
>  > the 2 sets of QUERY/FETCH required without them.
> 
> Err, I think you are mistaken in how non-stored queries work.  
> 
> The CUA does NOT first retrieve them from the CS (1 trip on the wire) 
> and then resend them to CS in a command (1 trip on the wire).   The CUA 
> simply crafts the query locally using whatever inputs it needs/has and 
> sends it.  Just the 1 trip I described, not the 2 you seem to think.

My point exactly. If I want the query named XXX and we do not support
VQUERY with QUERYID, then the CUA MUST do that 2 round trips.

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

> There are undiscussed issues related to stored queries such as:
> 
> 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.

If you qury for a UID that does not exist in the named TARGET
- you get an error.

If you qury for a QUIERYID that does not exist in the named TARGET
  - you get an error.


If you qury for ANY property that does not exist in the named TARGET
  - you get an error - even when it is not a VQUERY.

Not an issue.

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

  If you are talking about the TARGET in the VQUERY, then there is no
  difference to manually sending the same VQUERY even when it is not stored.

  Not an issue, So why do you feel it is different if it is stored or not?

  If you are talking about the TARGET at the CMD level, then there is no
  difference to manually sending the same VQUERY even when it is not stored.

  Not an issue. So why do you feel it is different if it is stored or not?

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

> All of these undiscussed issues contribute to the proposal that we pull 
> stored queries from CAP 1.0 and defer it to a later draft when they can 
> all be covered.  Especially since the feature as it currently exists 
> does not fulfill our original intent.

All of your assertions above are unfounded and unsubstantiated.
They are not real problems. They have nothing to do with the text in CAP.
Those problems do not exist in any way that is different from non-stored
queries.


> 

-- 

  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