Print

Print


My experience is that clients don't clean up after themselves.  They won't
send in deleteResultSet requests.  The wasted space on the server is the
server's problem and will be managed, as necessary, by the server.

Ralph

> -----Original Message-----
> From: Ray Denenberg [mailto:[log in to unmask]]
> Sent: Friday, June 14, 2002 5:53 PM
> To: [log in to unmask]
> Subject: session ids and result set ids
>
>
> 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
>