RE: CAP Example READ-1

[poepping@xxxxxxx]

I was going to raise the same issue as alex.

I think that once again we should ask for input from the IMAP
guys on search contexts and complexity on the server end..

yes, you need to name result sets, deal with garbage collection,
and add new error codes (that result set no longer exists since
the server restarted between requests).  This is a non-trivial
addition, and one that might be beyond the scope of rev1..  If
you have a configurable bound for the result set (or items in the
set), and allow for (non-)retrieval of specific components, then
'virtual scrollbars' might easily be added as an extension capability.

I'm also concerned about 'naming' objects (queries, contexts, or
whatever) on the server side, will someone clarify or propose the
idea for scoping rules on the server side?  I thought I heard global
naming for the queries (you can't define a query using the same name
that I already used), and I didn't hear a plan for the persistence
of the names (how long do you keep named queries lying around)..

Sorry if I missed it somewhere along the way..
mark.


> -----Original Message-----
> From: owner-ietf-calendar@imc.org [mailto:owner-ietf-calendar@imc.org]On
> Behalf Of Tony Small (Exchange)
> Sent: Friday, March 19, 1999 1:38 PM
> To: 'alext@cst.ca'; ietf-calendar@imc.org
> Subject: 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
> > > >