[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CAP Example READ-1
Good point. But I think this functionality is necessary.
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.
And if it doesn't exist, or for whatever other reason it fails, just return
an error.
Tony
-----Original Message-----
From: Alexander Taler [mailto:alext@cst.ca]
Sent: Friday, March 19, 1999 10:22 AM
To: ietf-calendar@imc.org
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. :-)
> >
> > -----Original Message-----
> > From: sman@netscape.com [mailto:sman@netscape.com]
> > 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:
> >
> > > 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: sman@netscape.com [mailto:sman@netscape.com]
> > > 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: .
>
> ----------------------------------------------------------------------
>
> Steve Mansour <sman@netscape.com>
> Judge, Jury, and Executioner
> Netscape
>
> Steve Mansour
> Judge, Jury, and Executioner <sman@netscape.com>
> 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