[ZOOM] Re: Scope of ZOOM (was Hello etc)
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