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
|