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

Sebastian Hammer quinn at indexdata.dk
Wed Nov 7 15:56:03 CET 2001


Sorry -- the "toy" statement was more provocative than I was aiming for.. I 
think we basically agree, and I wasn't looking to be confrontational.

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

I'm not proposing that it be relegated to the level of a toy and not
>useful in practice, but that we set a relatively low bar for what is to go
>into the ZOOM specification and what is to be left to the products that
>use ZOOM as their base.

I can agree with this. My sense is that you overrate the complexity of the 
database list question. It should not raise the bar of ZOOM in any 
meaningful way, since even if it does produce weird diagnostics from the 
server, I'm not expecting that ZOOM will mandate that any ZOOM API 
implementation will act on diagnostics in any other way than to pass them 
to the user.

I'd even be happy with a short warning in the spec to the effect that 
results are not always predictable if you send multidb queries against a 
target you're not intimately familiar.

>So long as the ZOOM base allows the extensions and hence the richly
>featured apps then there's no problem.  But to build all the rich features
>into ZOOM, I feel, defeats the point.  It's then -not- an Abstract API
>with some implementations, it's a client written up the same way in
>various languages.

>IMO, ZOOM should lower the intellectual barrier to entry of Z39.50, not
>provide people with a fully fledged Z39.50 implementation that simply
>needs a GUI dropped on top of it. There's no reason to implement multiple
>clients in multiple languages in that case and we should simply decide on
>one implementation and called it ZOOM.  No one wants to deal with ASN/BER,
>the complexities of this and that and the other -- that is the niche that
>ZOOM should fill in a way that makes sense, using an abstract API that can
>be implemented in a language of choice.

I don't think that statement makes sense at all. Why is an API that 
provides access to more protocol functionality closer to being a client 
than to being an abstract API? It's closer to being a "complete" API in 
Z39.50 terms, but I can't see that it requires you to write fewer lines of 
code to, say, build a GUI using that API.

I think Adam's earlier argument is heavier.... ZOOM is something that we 
will find it very tempting to apply to other IR-like protocols than Z39.50 
(WHOIS++, LDAP, SRW?). If we give very specific Z39.50 features a very 
central role, then this will be more complicated... and it would be a good 
reason not to include "largeSetLowerBound" as a core option, for instance.

But I don't rightly know if the subdivision of a server into multiple 
logical databases is a terribly Z39.50-specific thing.


More information about the ZOOM mailing list