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

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

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: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration            
    Phone: 978.399.6496
IBM Software Group                
        FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...