- From: Sebastian Hammer <quinn@indexdata.dk>
- Date: Wed, 07 Apr 2004 11:18:42 +0200
- 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 -- 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