Here's where I think we are:
Sessions have been deemed valuable. I dislike the security arguments, but
am persuaded by Pica's requirement to throttle the number of active users.
Pica's proposal was for a ticket from another service to be used. I don't
like that, because the use of the ticket will be mandatory (at least at
Pica) and will need to be documented as part of SRW for SRW clients to be
able to talk to Pica. That causes me to want the session mechanism to be
built into SRW. Since Pica intends to be an SRU implementor (speak up Rob
or Janifer if I've mispoken!) then the session mechanism can't reside in
SOAP headers. It must either be in the SRW/SRU message or in cookies.
Personally, I like the cookie solution, but doubt that we can require their
use at all the places where sessions are needed. So, the client bids for a
sessionID in a request and gets one (probably with a TTL (Time To Live)
value like resultSetID's). The sessionID will be used in subsequent
responses. (It would be polite if the server ignored the bid if it was
accompanied by a sessionID. I envision web forms with the bid as a static
hidden field that comes in on all requests, as the client might not know if
this was the first request or not.)
Is this close?
Ralph
|