Subject: Re: What good are stored VQUERYs?

From: [email-masked]
Date: Tue, 21 Jan 2003 14:53:11 -0500

Andrea wrote on 12/05/2002 04:23:14 AM:
> Well, we have something like that; at least, we had a proposal which
> several people including Doug agreed to. 

Ahh, this is the thread that Doug referenced in our ABNF discussion.  It 
was in late August when I was totally occupied with our endgame release so 
I didnt comment on it.  I never did play catch up on Aug/Sep 02 traffic 
yet, sorry.

> The idea is to add a TARGET property when operating with stored queries,
> to indicate where you want to store or fetch the query from.
> 
> Don't you think this would address your objections?

I dont think so.  My biggest objection is really the usefullness of stored 
VQUERYs given that there is no wildcarding of parameters in the query.  As 
such, each VQUERY used is going to have to be recrafted when sent.  For 
example, its impossible in the current query lingua to specify 'Find me 
all events that have an ALARM that triggers in the next 10 minutes'.  I 
can only craft querys for specific intervals: 'Find me all events that 
have an ALARM that triggers between 20030121T193000Z and 20030121T194000Z'

As such I have an aversion to mandating the storage of queries that 
essentially can only be useful for a limited window. 

I do agree about scoping QUERYID to the container level ala VCARs in the 
proposal.

However I have still have questions about A) the usefulness of stored 
querys and B) the applicability of stored queries to multiple TARGETs 
(VAGENDAs, etc).  Perhaps if you and/or Doug can educate me as to the 
usefulness of stored queries I could resolve B on my own...

> > I concur w/the "expect" bit.  I would hope that a CS would try to 
store 
> > unknown components in some blobular way such that the CS (Calendar 
> > _Store_) can act as a true Store for newer data w/o having to actually 

> > grok it fully.  Nowhere does it say in CAP that a CS needs to be able 
to 
> > decypher the intent/meaning of a component; it only talks about how it 

> > should be represented for querys, etc.  This has an implicit "any blob 

> > will work" mentality but thats just my take on the text.
> 
> I concur this is a desirable behavior, and one which would make
> extensibility much much easier. However, if this is the expected
> behavior, there should be something to that effect in the draft. I see
> nothing like that currently.

Neither do I.  Perhaps we overlooked it.  If not, then we need to chalk 
that gap up on the list of vague areas that need to be more clearly 
codified.

Doug, did we miss some text or is it just an implcit assumption we are all 
making?

> > If the CUA got back the 'empty' VQUERY you had at top then its not 
> > unlikely that a CU may see that there is nothing in the query and try 
to 
> > either delete it or modify it for their use.  The CUA _could_ prohibit 

> > this but again this gets back to the name space issue we have not 
> > addressed...
> 
> Personally, if my CS and my CUA both know that
> cap://cap.example.com/inet.it-stored-queries, then I'd write my CUA so
> that it doesn't show the CU anything about queries stored there. IMO 
this
> is just a form of an RPC so it's internal to the CUA and CS couple. This
> is useful if you have exclusive control of both; or if the stored 
queries
> are standardized.

Unless you are encoding in some name space prefix that you are hoping 
noone will also use (ie the "inet." prefix) then this is not a really safe 
thing to do.  If Lotus Notes (actually Domino) used its own implicit 
prefix and your product used its own then we could A) collide by accident 
or B) not interoperate as expected.

As noted its only useful "if you have exclusive control of both" and that 
defeats the interoperability we want to achieve.  While we seem to be in 
agreement for the most part on the issue of stored queries I think we 
disagree on what path to take going forward.

A compromise could be that we change QUERYID to be kind of like TZID in 
that if the first character is the soldus character then the rest of the 
ID is "CS defined".  This would allow you to access stored querys that are 
NOT encodable as a VQUERY since creating them is "Administration" and thus 
OOB for CAP 1.0.  The only other loose end would be to clearly define how 
a CS should respond to a query for unencodable data.  That is, if the 
"~AndreasQuery1" is NOT encodable as a VQUERY then we need a clearly 
defined response code or definition of what the CS should return to the 
requestor.

> I need to think more about this; I'm too busy ATM. Maybe we should
> find a way to discuss this more in depth between a few of us in a more
> interative way...

Now that Im back from vacation Ive got a few cycles to spend on this if 
you and others are interested in some concerted effort to deal w/this.

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

---

From: Andrea Campi <[email-masked]>
Date: Thu, 23 Jan 2003 16:01:58 +0100

> you and others are interested in some concerted effort to deal w/this.

Bruce,

before I answer each point in your email, let me remind you that
in one of my last emails in this thread I said that, as far as
I'm concerned, stored queries can be dropped from the draft
altogether, and that we can design it properly from scratch in
a separate draft; nobody objected to that. If we want to do that,
we need to make sure CS can store components they (and we) don't
know about yet.

That said, I think it would probably be wise to start talking
about how we'd like stored queries to be specified instead of
what's wrong with what we currently have. ;-)

Bye,
	Andrea

-- 
Andrea Campi                              mailto:[email-masked]
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy

---

From: [email-masked]
Date: Mon, 27 Jan 2003 13:55:33 -0500

Andrea wrote on 01/23/2003 10:01:58 AM:
> a separate draft; nobody objected to that. 

I agree.  So far no proponent of stored VQUERYs has come forward.  I would 
suggest that we remove them from the CAP 1.0 draft since they are 
inadequate or at best useless in the current form. 

>                                            If we want to do that,

That was a topic I was going to broach next based mored on your VTIMEZONE 
questions than this really.  Ill start that as a separate thread to avoid 
digressing from the VQUERY topic any more.

> what's wrong with what we currently have. ;-)

I already stated why I think they are useless; essentially no saved query 
is reusable beyond a certain span of time. There may be other issues (or 
others may have some) but right now I haven't spent any cycles on how to 
best fix this.  You seem to be more motivated to do this (or at least have 
some ideas in mind)...

Since we seem to all agree about removing stored VQUERYs I say "Move 
along... These aren't the topics you are interested in...."

Bruce