- From: Kevin Gamiel <kgamiel@cnidr.org>
- Date: Fri, 02 Apr 2004 09:49:25 -0500
- To: Alan Kent <ajk@mds.rmit.edu.au>
- Cc: ZIG <www-zig@w3.org>
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