[ZOOM] More on multiple result sets

Aaron Lav asl2 at pobox.com
Thu Jul 11 15:59:47 CEST 2002


I know this was discussed in the thread starting with
http://www.indexdata.dk/pipermail/zoom/2001-December/000158.html, 
but I have some more observations.

http://lcweb.loc.gov/z3950/agency/wisdom/result.html seems to
implicitly bless the use of named-result-set-negotiation with v2, and
claims that if the client sends a result set name other than 'default'
to a server which doesn't support it, the server should fail the
request (and, if the client tried to negotiate named result sets, may
close the connection).

My experience with LC's Endeavor (1.13) is that it indicates lack of
support for named result sets, but then takes neither approved error
action.  Instead, it seems to ignore the result set name entirely
(e.g. if I send search with rsn 'rs0', then search with 'rs1', then
present with 'rs0', I get data from 'rs1').

So what I do (inspired by Sebastian's comments), and I'd like to
either propose for standardization or be convinced to remove, is
define a new Connection option, 'multipleResultSets' (currently
'x-multipleResultSets'), which the implementation sets according to
its best guess about whether the server supports multiple result sets.
(My implementation's guess is currently based on the results of trying
to negotiate named result sets at init time, but an optimistic
implementation which always guessed TRUE would conform.)  If the
application knows better through some out-of-band mechanism, it can
set this value correctly (to deal with broken servers, or servers
which implement the functionality but can't negotiate it at init time).

(Admittedly, because of servers' license to unilaterally delete
result sets, even a correct TRUE value is of limited utility.)

As an implementor's note (is it worth having such an addendum?), I use
the multipleResultSets value to control whether I send 'default' or a
new result set name (generated from a counter of result sets created),
and, if multipleResultSets is FALSE, compare the counter in a
ResultSet to the current value before sending a Present request and
throw an exception if unequal, to avoid returning bogus data.

     Aaron (asl2 at pobox.com)







More information about the ZOOM mailing list