 |
 |
> If I use http basic authentication, I can enforce a login. > Or I can use > source IP to tell who they are... Please no! This causes havoc within HE when we might have students working from home, or non-University owned accomodation. I've even seen source ip used for sessioning, which confounds multiple clients on the same machine or caching (we once found a commercial website, where I would do the search and my boss got the results due to the fact we were both going through the same university cache!) > But without an explicit request to terminate the session, > there appears > to be no other mechanisms than to either > a) after each search request, leave each user logged in until their > session times out, or > b) terminate the session immediately after every search > response is sent. (b) is possible behaviour and is what I believe Ralph effectively does (or at least wanted the option to do). Assuming a static (or almost static) database, then any SRW request could be handled by repeating the previous query with a different start and end to the records returned. You can then start optimising by caching the last x queries where x is some value determined by available resources. > It isn't really an issue of resources consumed by open > sessions, I could > care less about that. Its more of a question on how to accomodate the > business model where institutional access to a database is sold on a > simultaneous user basis. In this model, users are counted as > simultaneous users from the moment they do their first search, until > they explicitly logout, or timeout. As Rob has indicated this is a business model, and one where we have had quite a bit of discussion. Unlike Z39.50 SRW is not necessarily tied down to a simultaneous user model where a connected user may be consuming resources without actually doing anything. SRW works on a simultaneous request model. Given that the number of active users don't all issue a query simultaneously, the number of active users can be much larger that the number of active requests - i.e. SRW can support implementations that are more efficient than the connection based ones. > One possible way to tell the difference between 'normal' users who are > doing searches and 'federated systems' might be to compare > their values > for maximumRecords. I suspect most clients searching a single target > will have some positive value here and many federated system > might have > maximumRecords=0 if they are in the discovery mode. My > server could log > out any user after responding to a maximumRecords=0 request, but > otherwise leave them logged in. Possibly - however, a client may send a maximumRecords=0 request if they want to find out how large a record set is before retrieving results, but having got the size of the result set, then go on to retreive the first 10 records, next 10 records etc. As Rob indicates, one possibility is the 1.1 resultSetTTL value which the client can use to indicate how long the result set should hang around. I can't remember all the discussion on this, but perhaps a resultSetTTL of 0 could be used to explicitly terminate the result set. However, it isn't clear to me that this is a session in your business model? i.e. a user logs in, does some (possibly more than one search) and logs out. We don't define how in SRW an authentication token is obtained, and ditto for how it is released. Also if you are using HTTP 1.1 you also have the option of using keep-alive, i.e. the http connection stays open for multiple http requests/response so you can regard the sesison as over when the http connection is closed. Of course, for this to work in the general federated case, you probably want all the SRW servers you are searching to have the same behaviour. This is probably best done as a federated SRW profile than part of the core SRW spec (others may differ on this point). Matthew