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

Doug wished on 09/04/2003 01:42:12 PM:
> Bruce - 4 people replied today - two said yes (me and it looks as if
> Bernard by replying is saying yes, you said no, and Andrea
> said no). 

Umm, you better actually read what Bernard wrote.  He said:

In February 2002, Steltor (formerly CS&T, and now Oracle) proposed
to rename the property QUERYNAME to QUERYID and to add a new property
NAME to specify a localizable display name.

VQUERY components should be referred to with their unique QUERYID not
their NAME which may not be unique.

Thats not an endorsement of stored queries.  He's merely giving history to 
their contribution that you referenced. 

>           Bernard proposed the NAME/QUERYID change - do you want
> us to think that that means 'NO' to stored queries?

You are incorrectly trying to link what Bernard clarified to a my issue of 
stored queries.  You should be thinking of the other issue I raised: the 
incorrect inclusion of NAME in the searching for a stored query.  The 
latter is related to the former but goes away if the former is removed as 
Ive proposed.

> And you just posted TODAY - so don't you feel just a little
> bit embarrassed that you declare 'Everyone from 2 of the other
> editors...' question ... it?

If you are trying to bait me into something it wont work.  The issue was 
raised at the San Diego IETF (I think) and nobody there could find a 
compelling reason to keep them given the limitation of our query language 
(which I believe you proposed be simplified under the Subject "I MOVE we 
simplify the query language." back in early 2002). 

The plain fact of the matter is that stored queries failed to meet our 
original intent because the query language cannot support what we thought 
we could design.  Because of this and because of several 
unspecified/unanswer related issues I agree w/Andrea that it should be 
removed from CAP and left for a later draft to properly design and 
specify.

> And you have failed to find *anything* that supports your
> assertion of the 'original intent'.

Are you now saying that the original intent of stored queries was NOT for 
thin clients?  Gee, you previously confirmed what I said when you wrote:

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

but I guess you will say I misquoted you.

The motivation has it roots as far back as 1998 when Surendra Reddy 
mentioned it in the context of Simple Internet Calendar Access Protocol. 
Its also been discussed in the context of the original intent often in 
other discussions over the past couple of years. 

In fact, a scan of my archive reveals that this kind of issue was at least 
partly recognized by John Stracke back in March 2003 when he replied to 
you with:

Besides, as things stand, a stored query would be useless for "today's 
alarms", or "today's events", because the query language has no term for 
"today".

Your attempts to question the original intent aside (hey, theres that 
pesky word 'original' again.  I wonder...) I am still proposing that we 
simplify CAP by removing stored queries and that they be deferred to a 
later draft where all issues can be properly delt with.

We simplified the query lingua to speed up CAP but as a side effect we 
gutted the stored queries ability to fulfill our original intent.  We 
should further simplify CAP and remove all references to stored queries 
for CAP 1.0.

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