Date:         Fri, 14 Jun 2002 12:29:24 +1000
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Alan Kent <[log in to unmask]>
Subject:      Re: result set model for srw
Comments: To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
In-Reply-To:  <[log in to unmask]>; from Ray Denenberg on Thu, Jun 13,
              2002 at 11:08:21AM -0400
Content-Type: text/plain; charset=us-ascii

On Thu, Jun 13, 2002 at 11:08:21AM -0400, Ray Denenberg wrote:
> Alan Kent wrote:
>
> > I agree with Rob's sentiments, but sort of agree with Jan about
> > the niceness of merging SORT into CQL.
>
> I need to ask you the same question I asked Jan yesterday: do you really
> mean in CQL or would a separate SRW parameter be sufficient?

Time zones and overlaps are fun. I had meant I could be convinced that
it has a place in CQL. I am happy(er) to have it a separate parameter.

> If we have (persistent) result set names, do we still need session ids?
>
> --Ray

One unanswered question to me (it might have been decided already sorry):
who invents result sets names? If the server just generates them, is
there any obligation for the name to be sensible? If a user is going
to use in a follow up query, then it should be sensible shouldn't it?

Z39.50 of course uses the approach that the client gets to suggest whatever
name it wants. There are lots of different approaches here, so maybe
I should not be suggesting another, but...

    Have clients supply a result set name if they want the server to try
    to keep the result set around.

    Have servers return a session id if the server will try to keep state.
    (The session ID would be some big unique hard to guess string.)
    A server only needs to return a session id if a result set name was
    proposed by the client.

    Clients can send a session id with followup requests if they choose to.

    Any client request using an expired session id returns an error.

The session id therefore identifies the ZAssociation created for that user.
If the session has gone, the client knows about it. If the client does not
care about sessions, then it never sends in a result set name. If a server
does not receive a result set name from a client, it does not need to
maintain a session for the client. A server can always refuse to keep
a result set around (by not returning a session id). A server can choose
to cache query results so if a client sends the same query several times
in a row (maybe asking for different records out of the query results),
the server can choose to reuse an old result set it has lying around,
or redo the query. If a reference to an old result set is used howver,
the server must guarantee to use the old result set or fail.

Alan