 |
 |
That sure looks like a session ID. I don't think anyone else would be fooled. Once we admit that, we get into the whole session management business. We said that eliminating sessions was one of the simplifying assumptions of ZNG. I still think that was a good decision. Ralph > -----Original Message----- > From: Janifer Gatenby [mailto:[log in to unmask]] > Sent: Thursday, July 12, 2001 10:13 AM > To: [log in to unmask] > Subject: Re: why do we even want the result set name? > > > Pica server will assign result set names. > > This may be a little late in the day to be adding another proposition, > sincere apologies, but...... We would also like the Search > response to > include a "server user id substitute". This can be returned > in the ZNG:user > field for subsequent requests and avoid the user id and > password having to > be sent in multiple requests. It can also serve to guarantee > the "actual > user" (there may be more than 1 user able to use the same > user ID/password) > a time slot on the server, because the system has a finite number of > concurrent users. Pica also uses this for being able to return search > history, i.e. a notion of session, but this is out of ZNG scope. > > Would it also be acceptable to include this much (ZNG:user) > in the search > url as well as in the SOAP message? > > Janifer > > > -----Original Message----- > From: Z39.50 Next-Generation Initiative [mailto:[log in to unmask]]On Behalf Of Ray Denenberg Sent: Thursday, 12 July 2001 13:44 To: [log in to unmask] Subject: Re: why do we even want the result set name? From: "Matthew Dovey" <[log in to unmask]> > As for why we need the server to return the result set, this was discussed > at the meeting and again via e-mail last week, ....... But we've changed the assumptions. At the meeting, the firm assumption was that results would be static in the case where a result set name is supplied. .... And another important assumption is (was) that the result set corresponds to the original query string.... > However at this point unknown to us someone adds a new record ..... What's the mechanism you envision to add a record? It doesn't fit the model as we've discussed so far. Would you only be able to add a record that conforms to the original query? Or could someone "qualify" the result set (e.g. A OR b), in which case the result set no longer corresponds to the original query string. Let me ask, and please everyone think about this, is anyone planning to *use* the result set name feature in the initial testbed, and if not, would it be reasonable to mention it in the initial report as something we will study in detail and may (/probably-will) add in the next release, but leave it out as an actual parameter for now? --Ray