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

Doug responded on 09/04/2003 11:49:46 AM:
> > 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'm not the only one who have questioned this dubious feature.  At the 
last IETF I was at everyone there questioned it for the exact reasons I 
described.

Had stored queries been able to achieve the original intent I would not 
question them in CAP 1.0 but they do not remotely approach solving the 
original intent and they put an implicit burden on ALL CSs so I question 
their inclusion.

I can see their use for non-wildcarded cases but they do not fulfill our 
original intent for the feature.  Because of this and because of the extra 
load it places on every CS (since there is NO way under CAP-12-a to opt 
out of it) I concur with Andrea in that it should be removed and left 
until a later draft. 

Since Doug seems to be proficient at extra drafts perhaps he can flesh one 
out that will achieve the original intent...

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

I proposed that all references to stored queries be removed from CAP 1.0. 
Or perhaps you missed that in nearly all my other postings on the subject. 
 

> So what's your point? Do you want to propose that we add text
> saying "do not do something unless it is useful"?

<FRUSTRATION SHOW=ON>
Perhaps I should propose we get a co-editor who will pay attention to 
postings on issues w/o trying to ignore or deflect them in an attempt to 
get CAP 1.0 out the door ASAP.
</FRUSTRATION>

Proposal: We remove any and all references to stored queries in CAP 1.0. 
Anyone interested in extending CAP such that the original intent of stored 
queries is achieved can do so in a later draft.

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

If its obvious then why is it such a big deal to get it removed?

At the last IETF I was at with the Steltor folks they all questioned the 
usefulness of stored queries given our query language.  So did Steve 
Mansour.  That's 2 of the co-editors of CAP.  Sure, stored queries can be 
used but none has been able to show that we are able to achieve the 
original intent to any real degree (1 example for ~50 octets is hardly any 
benefit).

Given the cost of implementation vs the degree of inability to achieve the 
intent of the feature I propose (in case you missed it before) that we 
remove all references to stored queries from CAP 1.0 and leave it to a 
later draft to add the feature properly.

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

Oh, so you think that the CUA is always going to retrieve the VQUERY from 
the CS and then resend it back to the CS on any of those commands?!?  Why? 
 If the CUA knows it wants to find all unprocessed entries it can use a 
hardcoded query and just send it; there's no need to go find it and then 
resend it.

There's never been any implicit or explicit need for the CUA to first find 
the query in the CS and then use it.  My CUA should be able to craft and 
send queries just fine w/o expecting to get them from the CS.  After all, 
just how would your CUA be able to "Find the query that retrieves all 
entries on my calendar for XXX" where XXX is some arbitrary date/time 
value?  The CUA should have no problem calculating the XXX value based on 
some UI inputs (ie: the current date being displayed) and filling in the 
blank before sending the query.  Unless of course you never wrote code 
that used Cscanf() before...

> Looks beneficial and efficient to me to just say:

Saving ~50 octets is hardly efficient when you factor in that the CS has 
to always be able to support stored queries and that the original intent 
for stored queries is unreachable given our current model/design (with 1 
exception).

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

Huh?  My cell phone has a built in calendar.  From there I can pick the 
day to see entries on.  That's all that the CU needs to do to get data; 
the underlying CAP engine does the rest.  (Are you expecting CUs to be 
doing query crafting manually instead of letting the CUA do it?? I don't 
want to be beta testing your CUA if that's true...)

If it had a CAP engine, it would have NO way to access any kind of stored 
query on my CS to get the events for "Today" or the day I pick at random! 
None.  The CAP engine in my cell phone MUST craft up the query with the 
"WHERE DTSTART<=[the selected day] AND DTEND>=[the selected day]" and send 
it.  There is NO way around it and that's exactly why the stored query 
feature in CAP 1.0 fails to meet the original intent. 

"[T]he ability to modify the result set" is totally unrelated to the issue 
of query storage!  Post processing of any kind is not relevant to the 
issue of using stored queries or queries within the command.

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

Umm, is this germane?  I'm not sure what you are referring to so I cant 
respond. 

> Something was demonstrated you comment on it below.

Your 4 examples were unremarkable and uncompelling.  You duplicated 1 and 
the other 2 were not related to the intent of the feature. 

Of the sole releveant example the only savings was ~50 octets.  To me, 50 
octets is not that compelling given its only for 1 example and there are 
NO other examples that fulfill the original intent.  All the other 
examples you provided were not typical common or frequently used queries 
and as such are hardly compelling incentive to keep the feature in (unless 
you've got code that already does it and don't want to tie it off until a 
later draft.)

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

There is no great need for some fancy GUI on thin clients Doug.  My LG 610 
has a built in calendar that allows me to create entries on it and have 
alarms set, etc.  I press 1 button to get the current month and then use 
my arrow buttons to pick a day.  From there any entries I have for that 
day appear.  I can also create new entries or remove those that are there 
(or update them w/alarms).

If I were to try and use CAP to get data from my calendar then the phone 
MUST craft a query like "QUERY:SELECT VEVENT FROM VAGENDA WHERE 
DTSTART<=[date I selected] AND DTEND>=[date I selected]" where the date 
values are based on the day I selected via arrow buttons.  The CAP engine 
simply takes the date I picked and then Cscanf()'s it into the query and 
sends it.  No big GUI needs.  No benefit to using a stored query since it 
cannot wildcard the selected date into the query.  Just a simple Cscanf() 
into a buffer and then send it.

Originally we had envisioned being able to say "QUERYID:Todays_events" and 
the CS would be able to find them for my cell phone, no need for it to 
craft the QUERY.  However we failed to make the query language robust (or 
flexible) enough to convey wildcarded or fixed semantics (ie: "Today"). As 
such the thin clients have no way to get the benefit we intended and the 
CS implementations are implicitly mandated to support stored queries. 

>                               Stored queries allows their search results
> to be configured for them. 

Where do you come up with this stuff?  Referencing a stored query has 
NOTHING to do with any kind of results processing.

A stored query was intended as a means to minimize the CUAs need to send 
the frequently used querys in a command; the query was already on the CS 
so it could be just referenced by QUERYID and the CS would find and use it 
instead of parse the command for the query and perform it. 

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

Umm, ~50 octets is hardly that big an impact if the 'thin' client expects 
to be able to hold any amount of possible calendar data returned on the 
search.  After all we dont have a way to throttle off the SEARCH command 
results when too much data is returned short of shutting the BEEP channel. 


So again I propose that we remove all references to stored queries in CAP 
1.0 and anyone interested in extending CAP such that the original intent 
of stored queries is achieved can do so in a later draft.

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