 |
 |
Ralph of course if we have result sets there is session management going on anyway - at least in the background mark On Thu, 12 Jul 2001, LeVan,Ralph wrote: > 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 >