Theo van Veen wrote:
> I agree with resultsets being independ sessions as far as the client concerns. If the server wants to relate them, it is up to the server, as long as the client not needs to be aware.
I don't think we decided that. The way I understand it (and how it's currently described in the draft result set model -- see http://www.loc.gov/z3950/agency/zing/resultsetmodel.html), suppose a client gets a session id and a result set id in a response. The client can then supply that session id in a subsequent request, which might include a new query. The server would create a new result set which
too would be associated with that session. That way, the client might then use both result sets in a subsequent query (if they were associated with different sessions it couldn't do that).
> 4.
> Sorting existing resultsets is OK for me. Does the server return a new resultsetid after sorting, keeping the previous resulset available under is old name?
Same question I had. There are three possibilities: (1) new set, discard old; (2) new set, keep old; (3) no new set (re-write old set). Should the protocol specify this behavior or leave it to the server?
Note that the (draft) result set model now says: "... the sorted result set would be given a new result set id and the original result set might be discarded, at the discretion of the server". Meaning either (1) or (2), but that (3) would not be allowed (if we adopt this part of the model).
> 5.
> By adding recordnumbers to records from a resultsets the recordnumbers would automatically be a surrogate or placeholder when a record is missing.
However the scheme we've tentatively adopted doesn't include explicit record numbers but the record number can be inferred positionally.
> When there are no record numbers this may be interpreted as there being no persistant resultset.
Don't understand.
--Ray
|