Re: Distributed searches in Z39.50?

Alan Kent wrote:
> Hmmm. Resource reports, resource controls, extended services, other-info:
> I agree there is ample scope to add in something using an EXTERNAL.
> I think the next question then is whether it matters if the client has
> to poll for updates or whether the server should squirt async messages
> at the client when it discovers something new to tell the client.
> The answer to this question will determine which existing Z39.50 protocol
> features could be used to support a profile. I do think its important
> to be able to do present requests before the search has finished running.
> I think async messages sounds good, but I am not convinced its actually
> important - what is wrong with a client polling the server once per second?
> (Hmmm. Unless you have 1000 users of course!)
> 
> Is this what you meant by concurrent operations perhaps? Client sends
> a Search request. Whenver the server thinks it appropriate, it sends
> a ResourceContol to the client with updated information. Eventually
> the server sends a Search response when all distributed searches have
> completed. The client however needs to be allowed to do a present
> request against the result set name before the search response comes
> back, which requires support for concurrent operations.

Yeah, I think the proper way to do this is using event-driven concurrent 
operations, but it definitely increases the complexity of the client.


> Without concurrent operations, I suspect the client would have to poll
> for updates on search progress no matter what Z39.50 features was
> used. This seems a little CPU wasteful, but probably easier to
> implement in practice. I am thinking of things like ZOOM APIs. Having
> strict client-request/server-response pairs makes general purpose APIs
> much easier to implement. It also avoids mandating 'event model' style
> programming.

I'm not advocating this approach, but you could write a profile that 
required no change/additions to PDUs (hence underlying z39.50 
libraries), only in higher-level application logic.  For example, you 
could fake asynchronous operation where a searchRequest gets an 
immediate searchResponse with resultSetStatus of interim.  The client 
may then poll the server with additional searchRequests (perhaps 
maintaining a common referenceId) until either resultSetStatus is none 
OR if the client wants to stop the search it could send a searchRequest 
with a flag set, telling the server to stop the search.  The client 
could also do normal presents between polls.  Note that the profile 
would probably change the intended semantics for resultSetStatus, as 
well as searchRequests and searchResponses.

Kevin


-- 
Kevin Gamiel <kgamiel@cnidr.org>
MCNC Center for Networked Information Discovery and Retrieval (CNIDR)
http://www.mcnc.org
http://www.cnidr.org

Received on Friday, 2 April 2004 09:50:49 UTC