[ZOOM] Responses to Qns

Mike Taylor mike at seatbooker.net
Tue Jul 16 17:19:46 CEST 2002

> Date: Tue, 16 Jul 2002 13:11:33 +0100 (BST)
> From: Robert Sanderson <azaroth at liverpool.ac.uk>
> > (Hope the ZiNG meeting went well ...  Any chance of a report from
> > a ZOOMish perspective?)
> Err, there really wasn't anything ZOOMish talked about to report.  I
> mentioned half heartedly the idea of having a ZOOM/SRW binding, but
> Matthew pointed out that you can't execute functions on objects
> returned from a web service.

Well, first of all, this was supposed to be a ZiNG meeting, not an SRW
meeting!  You'll recall from the MA's own ZiNG page at
that the ZiNG umbrella encompasses ZOOM and ZeeRex as well as the
ubquity that is SRU/W.  Oh well.

> Of course we have ZOOM bindings for non OO languages, so I think
> that it's not such a dead idea as Matthew has it.

Also true.  OO is merely a frame of mind, right?  :-)

I could fake up a Web Services "hello world" session if I could be
bothered, but I'll do that in a different message (if at all).

> > I think we're just talking about one option -- a single concession
> > to server brokenness -- that means "Watch it!  This server will
> > lie to you."  I'm open to that.  I certainly don't see us trying
> > to define a great raft of options to describe specific server bugs
> > in detail.
> My thought is that if it's not an X-, does that mean that everyone
> needs to support it?  This isn't as simple a case as just copying
> the elementset across on to the result set as mine, it requires some
> actual processing which seems to almost certainly include at least 6
> network transactions:
> search    (create rs1)
> sort rs1      
> present from rs1
> search    (create rs2)
> sort rs2
> present from rs1

I have to admit that I don't really follow this argument.

What's propose is a single option which can be used to tell the ZOOM
client library "don't use result-set names other than 'default' on
this connection".  Now _one_ of reasons you might want this is because
the connection is to a server which, whatever it might have told you
at negotiation time, doesn't support multiple (named) result sets.

> And this is just to avoid a broken Voyager server that misrepresents
> its capabilities?


But no, it's also to support clients which only need one result set at
a time, and wish to politely avoid requiring the server to maintain
multiple, unnecessary result sets.

> How about a function on the connection that returns an array of
> errors about the server?  Then you can call it if you think that
> you're talking to an unreliable server, but if you're talking to a
> known server you don't waste the network traffic and processor
> cycles in determining that it's a good one.
> Something like:
> connection.serverReport()
> -> {"singleResultSet"}
> and any further 'heads up's that we define in the future.

Does anyone other than Rob like this idea?  :-)

> --------------------------------------------------
> source zoom-1.2.tcl
> object Connection conn "z3950.loc.gov" 7090
> conn.setOption "database" "Voyager"
> conn.setOption "preferredRecordSyntax" "MARC"
> object Query query1 0 "7 0253333490"
> set rs [conn.search [query1]]
> set rec [$rs.getRecord 0]
> puts [$rec.getRaw]
> -------------------------------------------------

Great, many thanks.  I've added it to

BTW., looking again at that page, I notice that it's pretty feeble: it
has no link to the Tcl binding specification, nor any information
about the Cheshire implementation.  That's _very_ out of date, isn't

If you can send me a link to the binding documentation (there is some,
right?) and to downloadable source, I'll update the binding

(I'll answer your last point in a separate message.)

 _/|_	 _______________________________________________________________
/o ) \/  Mike Taylor   <mike at miketaylor.org.uk>   www.miketaylor.org.uk
)_v__/\  "A mounted skeleton is not science.  It's art.  Its purpose is
	 to entertain the public, not to be a scientifically accurate
	 specimen" -- Brian Curtice.

More information about the ZOOM mailing list