[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CAP Example READ-1

To: ietf-calendar@xxxxxxx
Subject: RE: CAP Example READ-1
From: Doug Royer <Doug.Royer@xxxxxxx>
Date: Mon, 22 Mar 1999 12:40:54 -0800 (PST)
List-archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Reply-to: Doug Royer <Doug.Royer@xxxxxxx>
Sender: owner-ietf-calendar@xxxxxxx
> From: "Lisa Lippert (Dusseault) (Exchange)" <lisal@Exchange.Microsoft.com>
> 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.

> Lisa
> 
> -----Original Message-----
> From: sman@netscape.com [mailto:sman@netscape.com]
> Sent: Friday, March 19, 1999 12:47 PM
> To: alext@cst.ca
> Cc: ietf-calendar@imc.org
> 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. :-)
> > > >
> > > > -----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

-Doug
-------------------------------------------------------------------
Doug.Royer@Sun.COM		http://playground.sun.com/~dougr
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL
Prev by Date: Re: draft-ietf-calsch-locating-01.txt
Next by Date: Re: IRIP version 4 (Part 1) - ICALDATA
Previous by thread: RE: CAP Example READ-1
Next by thread: RE: CAP Example READ-1
Index(es):
- Date
- Thread