I'm interested in utilizing the Extended Services portion of the z39.50 protocol. I understand that some work is being done on koha's client. Are there any plans to implement ES for v3.0's z client? ES does not seem to be implemented in Net::z39.50 or in the zoom api. thanks, Ryan Higgins
On Wed 13 Jul, RC Higgins wrote:
I'm interested in utilizing the Extended Services portion of the z39.50 protocol. I understand that some work is being done on koha's client. Are there any plans to implement ES for v3.0's z client? ES does not seem to be implemented in Net::z39.50 or in the zoom api.
Slightly off topic, but I recently installed 2.2.3 after not using Koha for some time: the previous version was at least a year ago. The z3950 client seems to be worse than it was at finding data: even thought the daemon is running it will sit there for ages with that infuriating "?? to go" displaying on screen and often will not find data that I am sure should be in one of the servers it is looking in. Several years ago MJ Ray suggested replacing the daemon with a z3950 program that was called when needed: has this idea been completely dropped? It may be, of course, that I have set up the client incorrectly for one or more of the servers. Are there any detailed instructions anywhere? In particular I note that if the standard scheme is set up for the intranet the client will set the download to use MARC21 by default while if it is set up as NPL, MARC21 is not an option, and the default is USMARC. Does this make a difference? ie will some servers refuse to send data in particular versions of MARC and will Koha translate between them? And if a server is listed as only sending data using GRS-1 or SUTRS etc and not MARC, does that mean that it cannot be used with the Koha client? see eg http://copac.ac.uk/interfaces/z39.50/zed-support/ under "Record Syntaxes". (I have been told that COPAC is the biggest catalogue of academic books in the UK.) Can I suggest that in the next version the "checked" flag under "Add server" be set as true by default (which is presumably what most people will want). Am I right in thinking that the number in the next line (the order of display) makes no difference to the search itself? And finally, does the three seconds used by the daemon/script prevent data from being collected from slow servers, ie is the connection dropped before they can reply? If so, which script is it to be found in? And yet another thing :-) Would it be possible for the "found" display to show more detail, and if so which file needs altering? I search for textbooks and if a library has a particular textbook it may well have ten editions or more of it -- which will be displayed in a random order. It would be useful if before clicking on "add biblio" one could ensure that one was loading the correct edition. Roger -- Roger Horne, 11 New Square, Lincoln's Inn, London WC2A 3QB http://hrothgar.co.uk/YAWS/ mailto:roger@hrothgar.co.uk
Roger Horne <roger@hrothgar.co.uk> wrote:
Several years ago MJ Ray suggested replacing the daemon with a z3950 program that was called when needed: has this idea been completely dropped?
Years, really? The problem with it is that the z3950 servers would only have a relatively short time to answer. I've not dropped the idea, but I've no way to fund the necessary learning, experiments and programming time right now and just keep bodging the daemon for people.
It may be, of course, that I have set up the client incorrectly for one or more of the servers. Are there any detailed instructions anywhere?
It seems rather fiddly to debug IMO. Basically, one watches the z3950* tables and the daemon's logfile and see what it's saying as a query is submitted. Even so, I still had one of my client libraries banned from a z3950 server following undetected problems and repeated requests that were more-or-less a denial of service attack.
In particular I note that if the standard scheme is set up for the intranet the client will set the download to use MARC21 by default while if it is set up as NPL, MARC21 is not an option, and the default is USMARC. Does this make a difference? ie will some servers refuse to send data in particular versions of MARC and will Koha translate between them?
z3950daemon experts need to answer that, but I think MARC21 and USMARC are close enough to usually both work.
And if a server is listed as only sending data using GRS-1 or SUTRS etc and not MARC, does that mean that it cannot be used with the Koha client? [...]
I don't think we can use those ones. I don't think it would be too hard to extend koha to support that, but I'm working on the installer next.
And finally, does the three seconds used by the daemon/script prevent data from being collected from slow servers, ie is the connection dropped before they can reply? If so, which script is it to be found in?
z3950 is usually served over UDP, which is sort-of connectionless. I see COPAC only offers TCP. I'm not sure how that works with the daemon. I think I only have UDP servers working at present.
Would it be possible for the "found" display to show more detail, and if so which file needs altering? [...]
Get the URL of the "found" display (info or properties from the right-click menu if nothing else) and that tells you the script which may need altering. The script will probably name the tmpl file which will also need altering to display the extra output from the script. Hope that helps, -- MJ Ray (slef), K. Lynn, England, email see http://mjr.towers.org.uk/
participants (3)
-
MJ Ray -
RC Higgins -
Roger Horne