Mike Taylor wrote:
> So my concrete proposal is simply that the client should send, as a
> part of the search request, a bit saying whether or not it wants the
> server to maintain a persistent result set.
We explored all of this, in great depth, at our first meeting a year ago.
There was strong sentiment not to do this as it would be a futile effort to
define negotiation that wouldn't work in practice anyway.
> BTW., the SRW spec goes on to say --
> When the client subsequently wishes to retrieve records from
> the result set, it may send a Search/Retrieve request which
> includes either the same query string, or a query string that
> includes the server-supplied result set name if one was
> I feel strongly that these are two different things.
I think we would all agree.
> Consider a database that continually receives new records -- for
> example, a news-clippings database that gets a feed from Reuters. You
> want to set up an SRW client to poll it every ten minutes and pick up
> the newly-added records. So every ten minutes you do your search,
> sorted on date-of-entry, most recent first. You say "give me the
> first ten records", but if there are more than ten, you need to be
> able to back and say "give me the next ten" _from the existing result
> set". This is _very_ different from re-executing the search and
> fetching records 11-20 from the resulting set.
This is why we distinguish the two cases.
> Z39.50 classic was a bit vague on that.
No, I think Z39.50 is clear on the staticity of a result set. But Z39.50
doesn't talk about re-executing a query; it's out-of-scope -- there's
nothing to prevent it, and there is no special protocol significance to it.
Your point is well-taken. I think we should do the same in srw, just take
out all the prose about re-executing the query, and about the query string
being a result set identifier.
See related message on this.