Subject: CAP Example READ-1

From: [email-masked] (Steve Mansour)
Date: Wed, 17 Mar 1999 09:23:36 -0800

Example READ-1

This example shows how the READ command can be used to read events in a
particular time range from multiple calendars.

C: 10 READ VEVENT relcal2 ://bobo.ex.com/relcal3
S: 10 2.0 cap://cal.example.com/relcal2
S: 10 2.2 cap://bobo.ex.com/relcal3
C: 10 SENDDATA
S: 10 2.0.1
C: CONTENT-TYPE: text/calendar; method=read; component=VCOMMAND
C:
C: BEGIN:VCALENDAR
C: VERSION:2.1
C: METHOD:READ
C: BEGIN:VCOMMAND
C: BEGIN:VQUERY
C: MAXRESULTS:20
C: MAXSIZE:17000000
C: QUERYNAME:MyViewRange
C: QUERY:SELECT (DTSTART,DTEND,SUMMARY,UID);
C:   FROM VEVENT;
C:   WHERE (DTEND >= 19990310T080000Z AND DTSTART <= 19990310T190000Z);
C:   ORDERBY (DTSTART ASC, DTEND, UID, SUMMARY)
C: END:VQUERY
C: END:VCOMMAND
C: END:VCALENDAR
C: .
S: 10 2.0 cap://cal.example.com/relcal2
S: Content-type: text/calendar; Method=RESPONSE; Component=VDATA;
Optinfo=VERSION 2.1
S: Content-Transfer-Encoding: 7bit
S:
S: BEGIN:VCALENDAR
S: VERSION:2.1
S: METHOD:RESPONSE
S: BEGIN:VDATA
S: BEGIN:VEVENT
S: DTSTART:19990310T090000Z
S: DTEND:19990310T100000Z
S: UID:1234
S: SUMMARY:Big time meeting
S: END:VEVENT
S: BEGIN:VEVENT
S: DTSTART:19990310T130000Z
S: DTEND:19990310T133000Z
S: UID:5678
S: SUMMARY:small time meeting
S: END:VEVENT
S: END:VDATA
S: END:VCALENDAR
S: .
S: 10 2.0 cap://bobo.ex.com/relcal3
S: Content-type: text/calendar; Method=RESPONSE; Component=VDATA;
Optinfo=VERSION 2.1
S: Content-Transfer-Encoding: 7bit
S:
S: BEGIN:VCALENDAR
S: VERSION:2.1
S: METHOD:RESPONSE
S: BEGIN:VDATA
S: BEGIN:VEVENT
S: DTSTART:19990310T140000Z
S: DTEND:19990310T143000Z
S: UID:1919191
S: SUMMARY:Summer budget meeting
S: END:VEVENT
S: END:VDATA
S: END:VCALENDAR
S: .

---

From: Doug Royer <[email-masked]>
Date: Fri, 19 Mar 1999 17:00:58 -0800 (PST)

> Date: Fri, 19 Mar 1999 12:46:53 -0800
> From: [email-masked] (Steve Mansour)
> 
> hmm... I remember bringing that at the meeting: essentially to name or
> store the solution set to a query. There are issues with
> naming/storing/referring to them on the server. For instance, how long
> do you keep the solution set around? Most people just said to let the db
> subsystem worry about caching the querys/solution sets.
>
> Comments?
> 
> -Steve

Keep them as long as the authenticated entity is valid. Then toss them?

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: Doug Royer <[email-masked]>
Date: Fri, 19 Mar 1999 16:50:27 -0800 (PST)

Maybe we want to use SQL 'CURSOR's?  That's how SQL clients do it now for
dynamic binding (as I understand it).

Something like:

1) Define the QUERY by name (MyViewRange + cursor_name):

	C: ...
	C: BEGIN:VQUERY
	C: MAXSIZE:17000000
	C: QUERYNAME:MyViewRange
	C: QUERY:DECLARE cursor_name CURSOR FOR
	C:  SELECT DTSTART,DTEND,SUMMARY,UID;
	C:  FROM VEVENT;
	C:  WHERE (DTEND >= 19990310T080000Z AND DTSTART <= 19990310T190000Z);
	C:  ORDERBY (DTSTART ASC, DTEND, UID, SUMMARY)
	C: END:VQUERY
	C: ...
	
	(note MAXRESULTS was removed)

2) Then later in the same connection and session and perhaps in the same
   VCALENDAR mime packet, the CUA could send something like the following
   for each row to be retrieved:

	C: ...
 	C: BEGIN:VQUERY
	C: QUERYNAME:MyViewRange
	C: QUERY:FETCH NEXT FROM cursor_name
	C: END:VQUERY
	C: ...

Using standard SQL - no extensions needed.

-Doug

> From: "Tony Small (Exchange)" <[email-masked]>
> Date: Thu, 18 Mar 1999 17:31:30 -0800
> 
> Can we add a RESULTSTART property?  For instance:
> 
> C: MAXRESULTS:20
> C: RESULTSTART:10
> 
> This example would return the results 10 through 30.
> If there is no resultstart, then it's assumed to be zero.
> 
> If a CUA can retrieve a specific number of results, it would seem that it
> would also need to be able to retrieve results that follow.  We wouldn't
> want to have to retrieve more than needed.
> 
> Tony
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, March 17, 1999 9:24 AM
> To: CalSched IETF
> Subject: CAP Example READ-1
> 
> 
> Example READ-1
>

---

From: "Lisa Lippert (Dusseault) (Exchange)" <[email-masked]>
Date: Sun, 21 Mar 1999 13:34:40 -0800

The way to fix this is to index not on record number, but on a property
value or more than one property value.  So if I'm looking at a list of tasks
sorted by date entered, and I hit "page down", my CUA should take a look at
the value of the date entered of the last task showing, and ask for the next
screenful based on that value.

This is different than simply doing a query where the property is
constrained to being greater than a certain value.  If you consider a task
list sorted by category and then by title, there is no ordinary search query
that gives me 20 rows starting from category="personal" and title="Call
Mom".  It's related, but it's not quite the same thing.

Lisa

-----Original Message-----
From: Alexander Taler [mailto:[email-masked]]
Sent: Friday, March 19, 1999 10:22 AM
To: [email-masked]
Subject: Re: CAP Example READ-1

Unless the server stores the results of the initial search and
subsequent reads are performed on the same data set there are serious
problems with this approach.  

If data is deleted between queries the position of the results may
change, so that what was result 12 on the first query may become
result 8 for the second query.  If I query for the first 10 and then
second 10 I will never receive that information.  Similarly if data is
added I may end up receiving the same information twice.

So, if we really want the ability to incrementally retrieve data from
a search we need to add a facility for referencing search results on
the server.

Steve Mansour wrote:
> 
> OK that was probably it.  I like the resultstart, maxresults combination
the
> best.  Since that's what you proposed, I take it you prefer that as well.
> -Steve
> 
> "Tony Small (Exchange)" wrote:
> 
> > I originally suggested having two properties- resultstart and resultend.
> > Then I think Bruce Kahn suggested having resultstart with maxresults.
(I
> > cut out myself as the middleman. :-)
> >
> > Sent: Thursday, March 18, 1999 5:57 PM
> > To: Tony Small (Exchange)
> > Cc: CalSched IETF
> > Subject: Re: CAP Example READ-1
> >
> > This sounds reasonable to me.  I've made the update.  I think that
someone
> > at
> > the meeting might have had another suggestion (please speak up if you're
out
> > there).
> > -Steve
> >
> > "Tony Small (Exchange)" wrote:
> >
>   ----------------------------------------------------------------------
> 
>   Steve Mansour <[email-masked]>
>   Judge, Jury, and Executioner
>   Netscape
> 
>   Steve Mansour
>   Judge, Jury, and Executioner  <[email-masked]>
>   Netscape
>   Mountain View                 Fax: 650-937-2103
>   CA                            Work: 650-937-2378
>   94043                         Netscape Conference Address
>                                 Netscape Conference DLS Server
>   Additional Information:
>   Last Name     Mansour
>   First Name    Steve
>   Version       2.1

---

From: "Lisa Lippert (Dusseault) (Exchange)" <[email-masked]>
Date: Sun, 21 Mar 1999 13:34:41 -0800

Static searches are sometimes useful, but it annoys the user to be looking
through a list of online tasks and not see new ones as they appear.  Dynamic
or repeatedly refreshed searches are required client functionality, and yet
there are still ways of getting row-ranges from them.  Tony listed one, I
just outlined a more generalized principle.

Lisa

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 19, 1999 12:47 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: CAP Example READ-1

hmm... I remember bringing that at the meeting: essentially to name or store
the
solution set to a query. There are issues with naming/storing/referring to
them on
the server. For instance, how long do you keep the solution set around? Most
people
just said to let the db subsystem worry about caching the querys/solution
sets.

Comments?

-Steve

the
(I
someone
> > > at
> > > the meeting might have had another suggestion (please speak up if
you're out

---

From: "Frank Dawson" <[email-masked]>
Date: Mon, 22 Mar 1999 08:44:39 -0500

On Thursday, March 18, 1999 8:39 PM, Tony Small wrote, in part:

>Can we define what is meant in this example by MAXSIZE?  Is this the size
of
>all the items retrived or is this the maximum size of any single item?

Tony has a good point. This should be the maximum size of any single set of
search results returned. This was suggested in discussion to address the
needs of a small footprint CUA.

- - Frank

---

From: "Frank Dawson" <[email-masked]>
Date: Mon, 22 Mar 1999 09:08:18 -0500

On Friday, March 19, 1999 1:45 PM, Tony Small wrote, in part:

>Crazy idea: What if instead of RESULTSTART being an integer, have it be an
>id of a calendar item.  So for instance, I run the query on the first ten.
>I save the id of the last item I got and then set RESULTSTART to that id,
so
>the results start from there.

Hhmmm...Of course I like this idea. If you remember, I had suggested that
the READ function should be structured as a LOOKUP function, returning the
UIDs of any matches. That way, you could then READ them in the order and
number that you wanted. At the time, this was a minority view ;-)

However, this discussion thread points up that a CAP function set modeled on
this approach might be much more pragmatic. This will also help assist with
figuring out how to provide read access with some sort of flow control to
small footprint devices.

What do folks think? Shouldn't we reintroduce a LOOKUP or FIND function to
return UIDs of matches for containers that match a VQUERY and reuse the
existing READ to read data?

- - Frank

---

From: "Frank Dawson" <[email-masked]>
Date: Mon, 22 Mar 1999 08:43:03 -0500

>want to have to retrieve more than needed.

Tony: The results are not currently sequenced other than the ORDERBY clause
given in a VQUERY. If we wanted to further "order" them, what would we
sequence them by?

If you say you want 20 results, then I think the CS should return the first,
implementation-dependent 20 results. After that, if you ask for 20 more, you
get up to 20 more, but in an implementation and session-dependent sequence,
beyond that prescribed by any ORDERBY VQUERY clause.

Is this okay with everyone?

- - Frank

THAT IS,

---

From: "Frank Dawson" <[email-masked]>
Date: Mon, 22 Mar 1999 09:00:10 -0500

>added I may end up receiving the same information twice.

I agree with Alex. This seems much more complex for both the CUA and CS,
then the original approach. Which was: the CUA specifies that it can take
xxx number of search results at a time with each response limited to yyy
number of bytes. The CS would merely segment the responses into responses
that are less than or equal to this request.

Another question, though...is this a MUST that the CS responds according to
these MAXLENGTH and MAXRESULTS or is this a guide to the CS, in which case
it would be a SHOULD?

- - Frank

---

From: "Tony Small (Exchange)" <[email-masked]>
Date: Mon, 22 Mar 1999 10:36:39 -0800

Frank Dawson writes:

>> This (MAXSIZE) should be the maximum size of any single set of

Would having MAXSIZE refer to the size of a single item (as opposed to a set
of items) be more useful and also address the needs of small footprint CUAs?

I think of a scenario where I ask for the first twenty items and the first
19 are 1k each and the twentieth is 1 megabyte.  Should the whole thing be
rejected?  (And the other definition of MAXSIZE could be acheived by
multiplying this definition of MAXSIZE by the number of items requested - if
that number is known.)

Or do you imply MAXSIZE to mean something like, "give me all the items that
meet this criteria until the total reaches MAXSIZE."

Or could we acheive the functionality I'm looking for in the sql syntax?
For instance, find only items whose size are below a certain number?

Tony

---

From: Doug Royer <[email-masked]>
Date: Mon, 22 Mar 1999 12:35:13 -0800 (PST)

> From: "Lisa Lippert (Dusseault) (Exchange)" <[email-masked]>
> To: [email-masked], [email-masked]
> Date: Sun, 21 Mar 1999 13:34:40 -0800
> 

That is certainty one way to do it. What if 1000 of them have
the same date entered? Such as a bulk load of an event? We could
go through a list of possible and unlikely problems. I think there
is a more general solution (the SQL cursor or something similar).

There needs to be some way to optionally throttle the amount of data.
There is no restriction on how many components could be entered with
the same date/time entered.

-Doug

---

From: Doug Royer <[email-masked]>
Date: Mon, 22 Mar 1999 12:40:54 -0800 (PST)

> Date: Sun, 21 Mar 1999 13:34:41 -0800
> 

And how would your approach (in you previous post) show new events
that appear after you look at them? There is no 'date entered' property.
We only have LAST-MODIFIED and CREATED. And CREATED is the event
creation time, not the time is was entered into the store. So an event
could be stored that was created yesterday. It could be stored 1 second
after you just viewed that time range.

I do not think the problem (...see new ones as they appear) is solvable
with query. We deferred notification until CAP-2. Notification is what
would be required to implement seeing them as inserted into the store.
I don't see the above need as solvable with any query method.

-Doug