W3C home > Mailing lists > Public > www-zig@w3.org > April 2004

Re: Distributed searches in Z39.50?

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
Message-ID: <20040407000603.GB6580@io.mds.rmit.edu.au>

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.

Received on Tuesday, 6 April 2004 20:07:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:06 UTC