Subject: RE: CAP Example READ-1

From: "Lisa Lippert (Dusseault) (Exchange)" <[email-masked]>
Date: Thu, 8 Apr 1999 14:22:32 -0700

SQL Cursors are cool and work well, but this would require a lot of state to
be maintained on the server.  (Database servers are meant to do that, but we
haven't really discussed whether that style of interaction is intended for
CAP servers).  How many different calendar clients are going to have views
into how many different calendars on one server?  

If the client can re-establish the context with each new request, then the
server load becomes much more manageable.  That would require sending:
 - the original search query, including ORDERBY
 - the calid of the current item
 - (possibly) how many rows to return.
Now if the server happens to have the original search query cached it can be
fast, and if it doesn't it can still respond.

The problem with this is that the current item could be deleted, and the
server would have to respond with an error, but there are similar
difficulties with cursoring.

Lisa

-----Original Message-----
From: Doug Royer [mailto:[email-masked]]
Sent: Friday, March 19, 1999 4:50 PM
To: [email-masked]
Subject: RE: CAP Example READ-1

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
-------------------------------------------------------------------
[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: "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
> 
> 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: "Lisa Lippert (Dusseault) (Exchange)" <[email-masked]>
Date: Thu, 8 Apr 1999 14:25:51 -0700

You're right, I forgot that we would need notification to do truly dynamic
search folders.  But still, if a user asks for "first 20" items in a search,
then an item is inserted #25, then 10 minutes later asks for "second 20
items" in the same search, the user would like to see the new #25.

Lisa

-----Original Message-----
From: Doug Royer [mailto:[email-masked]]
Sent: Monday, March 22, 1999 12:41 PM
To: [email-masked]
Subject: RE: CAP Example READ-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.

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.

> 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
> 
> Alexander Taler wrote:
> 
> > 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

-Doug

---

From: Doug Royer <[email-masked]>
Date: Thu, 8 Apr 1999 19:13:09 -0700 (PDT)

> From: "Lisa Lippert (Dusseault) (Exchange)" <[email-masked]>
> Date: Thu, 8 Apr 1999 14:22:32 -0700 
> 

If it were done with a non-cursor method - it seems to me the same
state information would need to be maintained for the same number of
calendars on one server as with the cursor method?

> fast, and if it doesn't it can still respond.

Same with cursors - I don't see any difference here other then
the name and formatting of the method used to ask for the next data.

I simply proposed cursors because its an already standard thing
that we do not have to invent that many already know how to use.

-Doug

---

From: Doug Royer <[email-masked]>
Date: Thu, 8 Apr 1999 19:17:04 -0700 (PDT)

> Date: Thu, 8 Apr 1999 14:25:51 -0700 
> 

Agreed.

I think all of the proposals will work that way.

-Doug
Pager:				[email-masked]

---

From: "Lisa Lippert (Dusseault) (Exchange)" <[email-masked]>
Date: Fri, 9 Apr 1999 15:47:44 -0700

response below >>>

> calendars on one server as with the cursor method?

Not really.  If the client maintains state for its user (which it should
anyway), then the client can pass the state to the server with a new
request, and the server doesn't have to maintain state for that user.

Lisa

---

From: Doug Royer <[email-masked]>
Date: Fri, 9 Apr 1999 16:30:30 -0700 (PDT)

> Date: Fri, 9 Apr 1999 15:47:44 -0700 
> 
> response below >>>
> 
> > > SQL Cursors are cool and work well, but this would require 
> > > a lot of state to be maintained on the server.  (Database servers
> > > are meant to do that, but we haven't really discussed whether that
> > > style of interaction is intended for CAP servers).  How many different
> > > calendar clients are  going to have views into how many different
> > > calendars on one server?  
> > 

Sure it does.  We have a state-full protocol. That means
we keep session state including user information until that
user is done (by whatever method).

The query would have to be maintained until the state or query
was over. If not you could get the same results twice (or more) if
you did not keep query results.

	This could happen with the MIN-MAX method if the CS
	did not keep state information:
	
	At time T1 you query the CS for all VEVENTS today and ask
	for items 1-20 sorted by TRIGGER time. And say you get
	back 20 items all happened to between 9AM and 3PM.
	
	AT time T2 20 new VEVENTS are added, all of them
	with TRIGGER times between 1AM and 8AM.
	
	At time T3, you ask for items 21-30. If the CS did not keep
	the query results (state)- you get back the same 20 
	that was from your original (T1) query.

Thin clients would tend to only ask for one at a time anyway correct?

-Doug