[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
	http://www.loc.gov/z3950/agency/zing/zing.html
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
	http://zoom.z3950.org/bind/tcl/index.html

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
it?

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

(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