Print

---

Sorry I mispoke: the server would assign the session
id. Thus, a client sends a result set id, the server
send either (a) both a session id and result set id
(echoed), or (b) neither.

Ray Denenberg wrote:

> If we use session ids, can we then have the client
> (rather than the server) assign the result set id?
>
> Current discussion causes me to question the
> wisdom of having the server assign the id.  I
> don't want to recreate the complexity of Z39.50,
> but there are advantages to having the client
> assign the id. Suppose for example a client sends
> a query "cats" and the server creates result set
> rs1: ttl 2 months, 10 million hits. The client
> then sends "creampoint siamese cats" intending to
> narrow the search; the intent is to discard the
> first result set. The problem is there is no way
> to convey this. rs1, all 10 million records, will
> hang around, useless, for 2 months (pardon the
> hyperbole). If the client assigned the ids, no
> problem. Conversely, the client may want the
> server to keep the first set but do a new query
> (create a second set).  There's no way in srw to
> convey this, either.
>
> We chose to have the server assign the id for srw
> because of its sessionless nature. Now that we're
> talking about session id's, why not reconsider?
>
> The folks who want the session id seem to be happy
> if it's optional. Nobody seems to object to an
> *optional* session id. There is at least one
> implementor who claims not to support result set
> ids (Ralph).  Is it fair to say, though,  that if
> you do support result set ids then you support
> session ids?
>
> So if a client sends a session id, if the server
> supports it, he echoes it in the response and if
> not, ignores it (so if it is not echoed the client
> knows that the server doesn't support it).  And if
> the server doesn't support it, then it also
> doesn't support result set ids (and signifies this
> by not echoing it).
>
> Will this work?
>
> --Ray