- From: 'Alan Kent' <ajk@mds.rmit.edu.au>
- Date: Wed, 7 Apr 2004 10:06:03 +1000
- To: Alex Khokhlov <alex@lib.msu.ru>, www-zig@w3.org
On Tue, Apr 06, 2004 at 07:55:41PM +0400, Alex Khokhlov wrote: > I don't know if my information will be of any help for you or not, but I > would like to briefly describe the project I've done for the Moscow State > University Scientific Library last year... Thanks. It was interesting. Just to confirm my understanding, you have developed a Z39.50 distributed search client with a web interface. That is, users access a web interface and then your program does a distributed Z39.50 search (using lots of threads etc). My curiosity was a little different - I was wondering how to expose a Z39.50 interface instead of a web interface. That is, develop a server that allowed Z39.50 clients to access it where the server forwarded requests on to all the remote servers, did the query translations, record normalization, etc. The problem was that I was not sure how to use Z39.50 and get progressive results returned to a client - the client does not want to wait for all responses as that would be too slow. The answer is that there is a way to do it in Z39.50 using resource reports and concurrent operations (but no client exists that uses the capability). Is there a benefit over just having the clients do the distributed search directly (like what you have done)? It is not clear to me that there is a benefit. If it was easy to do within the protocol, then client writers might implement something. If its tricky, I think client writers would never bother (or if they did bother, they would go to the effort you have and do the distribution in the client). I was wondering if a simpler protocol approach that does not introduce concurrent operations into the mix (for clients - I don't care about servers) existed. I think a simpler approach may be necessary to result in a simple ZOOM API. As soon as you require multiple threads, async operations, etc, I think one of the goals of ZOOM (simple API for programmers to use) will start to disappear. But maybe there is a way to use concurrent operations etc under a ZOOM API without exposing that complexity to the programmer using the API. But maybe its always going to be tricky - clients have to progressively display results and let users view them. The protocol aspect is only one part of the complete problem that the client writer has to address. Thanks to everyone else who replied too. Interesting stuff. Alan
Received on Tuesday, 6 April 2004 20:07:06 UTC