Re: Z39.50 and URI

Simon E Spero (ses@tipper.oit.unc.edu)
Sat, 03 Sep 94 17:17:35 -0400

Message-Id: <9409032117.AA03454@tipper.oit.unc.edu>
To: hoymand@gate.net (Dirk Herr-Hoyman)
Subject: Re: Z39.50 and URI
In-Reply-To: Your message of "Sat, 03 Sep 94 10:29:46 EDT."
<199409031429.KAA39401@inca.gate.net>
Date: Sat, 03 Sep 94 17:17:35 -0400
From: Simon E Spero <ses@tipper.oit.unc.edu>

>>>>> "Dirk" == Dirk Herr-Hoyman <hoymand@gate.net> writes:

>> From personal coorespondence with Bob Waldstein
>> <wald@library.mt.att.com>,
Dirk> who is one of the principle developers of Z39.50. I'm in ">
"...

>> In a way, Z39.50 might not be a good choice for implementing
>> URN/URC server, as the response needs to be FAST.

Bob> I don't know whois++ servers, but the http servers I have
Bob> seen (CERN and NCSA) have not impressed me compared to my
Bob> Z39.50 server doing bland things - e.g. fetching a record by
Bob> single entry key, closest I can come to a file in
Bob> htdocs. And put a perl script in cgi-bin and http servers
Bob> are nearly by definition slow then. Plus getting a
Bob> record/page from a several million record DB is no different
Bob> (for me) than a 20 record DB).

As a protocol, whois++ is faster than Z39.50 unless the z39.50 server is
prepared to violate the spec by allowing inits to be made optional (this
was the appoarach used in the WAIS implementation of Z39.50/1988). For the
same reason, for single transactions, HTTP will be faster than Z39.50 for any
sensible implementation of HTTP. HTTP still has a lot of performance problems
build in to the design, and is still not really suitable for use as a
directory service, but it's more suited than Z39.50, which is overkill for
this application.

Simon