[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] Iterator ID.
1) As luck would have it, I wrote it that way. I guess I was thinking (like Jeff) that an iterator encodes (or maps to) the *state* of a result set. This would imply that the ID could change each time. 2) As far as an iterator being *required* in a searchResponse, I (thought I) was following version 7 of the XSD. (Isn't minOccurs=1 the default?) I would actually prefer that the iterator be *optional*. It makes little sense to return an iterator when there is an error or when we've just returned the last object in a result set. gpc Jeff Bohren wrote: >The purpose of the iterator ID is so that the client can ask the service >for the correct next batch of results. Since HTTP is a stateless >protocol, each web service request is independent of the one before. >Asking for data that corresponds to an ID known to both the client and >service is the mechanism for iterating. > >This is why the ID for each subsequent return does not need to be the >same. It may in fact be easier for the implementer to create a new ID >for each result set. > >Jeff Bohren >Product Architect >OpenNetwork Technologies, Inc > >Try the industry's only 100% .NET-enabled identity management software. >Download your free copy of Universal IdP Standard Edition today. Go to >www.opennetwork.com/eval. > > > >-----Original Message----- >From: Darran Rolls [mailto:Darran.Rolls@Sun.COM] >Sent: Tuesday, November 30, 2004 7:57 AM >To: Jeff Bohren >Cc: PSTC >Subject: Re: [provision] Iterator ID. > >I'm missing its purpose then... > >-djr > >Jeff Bohren wrote: > > > >>It does not seem that a search response should always return an >>iterator. If the search response contains the complete result set, an >>iterator is just extra baggage. >> >>There is no reason that the iterator ID has to be the same for every >>fetch. There is no harm in it, but there is no advantage either. I >> >> >would > > >>put it as: >> >>"The iterator ID returned from each subsequent call to iterateRequest >>MAY be the same as the ID included in the original search response." >> >>Jeff Bohren >>Product Architect >>OpenNetwork Technologies, Inc >> >>Try the industry's only 100% .NET-enabled identity management software. >>Download your free copy of Universal IdP Standard Edition today. Go to >>www.opennetwork.com/eval. >> >> >> >>-----Original Message----- >>From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] >>Sent: Monday, November 29, 2004 7:22 PM >>To: PSTC >>Subject: [provision] Iterator ID. >> >>A searchResponse may contain a <pso> but always contains an <iterator>. >> >> > > > >>An <iterator> has an "ID" attribute and may have "count" and >>"totalCount" attributes. >>- "count" represents the number of objects in the result set that the >><iterator> represents. >>- "totalCount" represents the number of objects that matched the <base> >> >> > > > >>and <select> elements of the <query> in the <searchRequest>. >> >>A requestor specifies the <iterator> that was output of a 'search' >>operation as input to an 'iterate' operation. In response to an >><iterateRequest>, a provider returns another <searchResponse> that >>contains the next <pso> and an <iterator>. >> >>Can the iterator ID change as the requestor iterates a result set? >>For example, assume that the original <searchResponse> contains >> <iterator ID="003" count="27" totalCount="27"/> >>and the requestor specifies this element in an <iterateRequest>. >>Can the provider now return a <searchResponse> that contains >> <iterator ID="004" count="27" totalCount="27"/>? >> >>Darran thinks that the ID must remain constant during iteration (i.e., >>any two iterators that represent the same result set should have the >>same ID), but I didn't come across anything that said so. >> >>Opinions? Recollections? >> >>gpc >> >> >>To unsubscribe from this mailing list (and be removed from the roster >> >> >of > > >>the OASIS TC), go to >>http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_wo >> >> >r > > >>kgroup.php. >> >> >>To unsubscribe from this mailing list (and be removed from the roster >> >> >of the OASIS TC), go to >http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_wor >kgroup.php. > > >> >> >> >> > >To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]