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

Re: Distributed searches in Z39.50?

From: Sebastian Hammer <quinn@indexdata.dk>
Date: Wed, 07 Apr 2004 11:18:42 +0200
Message-Id: <>
To: "'Alan Kent'" <ajk@mds.rmit.edu.au>, Alex Khokhlov <alex@lib.msu.ru>, www-zig@w3.org

At 10:06 07-04-2004 +1000, 'Alan Kent' wrote:

>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.

My impression is that it's a trade-off. If you imagine a client talking to 
a 'multiplexing' Z39.50 server and receiving asynchronous resource reports, 
the complexity of that client will be roughly comparable to a multiplexing 
client that does its own searches, etc. It's just that we're all used to 
developing the 'normal' kinds of clients, and managing a more complex 
communication over a single channel would be more challenging. I don't see 
any problem in hiding that kind of complexity behind, eg. ZOOM. In terms of 
bandwidth, you do save some init exchanges on the client-to-multiplexer 
connection... but since most Z39.50 clients these days tend to live inside 
webservers, I don't think bandwidth is usually the main concern

>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.

Yep. It's pretty easy to write a simple multiplexing Z39.50 client. It's 
quite a challenge to write a really good one.

Sebastian Hammer, Index Data <http://www.indexdata.dk/>
Ph: +45 3341 0100, Fax: +45 3341 0101
Received on Wednesday, 7 April 2004 05:19:50 UTC

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