[ZOOM] Re: Scope of ZOOM (was Hello etc)

Sebastian Hammer quinn at indexdata.dk
Wed Nov 7 16:10:19 CET 2001

At 02:52 PM 11/7/2001 +0000, Robert Sanderson wrote:

>People (or as much as I represent 'people' :) )  don't honestly care that
>a single server can maintain multiple databases beyond having a single
>port and Explain across them all.

But some of them do, if those two databases each contain something that is 
of use to them.

The most classic example may be a bibliographic union catalog which 
contains records from a collection of different libraries. It may be set up 
so you can search all databases in common (say, using the name "ALL"), or 
you can search any combination of the participating libraries.

It is assumed, in this constructed example, that the server will know how 
to carry out the searching and merging efficiently, and present you with a 
single, nice result set.

Yes, you could have just searched each database in turn or in parallel, but 
then you would be stuck fetching all the records and doing the merging on 
the client side. Not good.. it's expensive to fetch a large collection of 
records, and there's a very good chance the server knows how to do the 
merge better than you do.

Multiple-database searches are not *universally* useful, but they are 
useful in some specific applications where Z39.50 happens to be in common use.

>When I do a search, I think about it as searching a database with some
>parameters to say what exactly I want out of it.  Maybe I do that on
>multiple databases. Maybe those databases are on multiple machines. The
>fundamentals of *how the searching is done* is what ZOOM should be hiding
>from people who don't care.

I absolutely disagree that ZOOM should hide the complexities of 
multiple-database searches to the point of integrating result sets. That 
*is* an incredibly difficult task, which would raise the bar tremendously 
for ZOOM, and, indeed, bring it much closer to the application layer. 
Unless Mike kan get us some EU research money to do the job!

>If they did care, then why would they use ZOOM and not one of the many
>toolkits or implementations?

I'd go as far as saying that one of the main parameters of competition 
between Z39.50 *clients* (not APIs) is how well they cope (or not) with the 
substantial difficulties of multi-target searching. I think what ZOOM can 
meaningfully add is to solve the "easy" problem, which is to hide event 
handling and asynchronous network I/O as much as possible without 
jeopardising flexibility. It shouldn't try to seamlessly hide multi-target 
searching, because that is a job for smarter folks -- specifically folks 
closer to the application and the data being exchanged. What we *can* 
contribute is to free up some of their brain cells from worrying about 
Z39.50, so they can write cool client apps.


More information about the ZOOM mailing list