> >In response to Ray. I prefer sessionid's and resultsetid's
> >to be independent of each other, but the server is of
> >course free to make the sessionid part of the resultsetid.
> My question is about the relationship of result sets and sessions (not
> their respective ids). Does a result set expire when its session does, even
> though the result set ttl hasn't expired? (Rob say it does.)
This Rob thinks that they should as well, with the following question:
How does a session actually expire?
Will sessionids have a TTL as well? In which case a resultset with a TTL
longer than the session's TTL is just incorrect.
If they don't have a TTL, then are they just silently expired with no
warning? In which case I would suggest that sessions shouldn't be expired
while they have resultsets that still have time left to live as this is
contrary to the only information presented to the client.
Obviously if the implementation maps a session on to a Z Association and
the connection to the Z server goes down, then the SRW server is in an
error state regardless.
(Is there a list of SR[WU] diagnostics somewhere, by the way?)
,'/:. Rob Sanderson ([log in to unmask])
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Twin Cathedrals: telnet: liverpool.o-r-g.org 7777
____/:::::::::::::. WWW: http://liverpool.o-r-g.org:8000/
I L L U M I N A T I