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