From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: hoymand@gate.net (Dirk Herr-Hoyman), wald@library.mt.att.com
Subject: Re: Z39.50 and URI
In-Reply-To: Your message of "Sat, 03 Sep 1994 10:29:46 -0400."
<199409031429.KAA39401@inca.gate.net>
Date: Sat, 03 Sep 1994 12:28:13 -0500
Message-Id: <11825.778613293@moose.cs.indiana.edu>
Thus wrote:
>From personal coorespondence with Bob Waldstein <wald@library.mt.att.com>,
>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.
>
>I don't know whois++ servers, but the http servers I have seen (CERN
>and NCSA) have not impressed me compared to my Z39.50 server doing
>bland things - e.g. fetching a record by single entry key, closest
>I can come to a file in htdocs. And put a perl script in cgi-bin
>and http servers are nearly by definition slow then.
Indeed, current servers are not designed for speed, either at the
session layer (vanilla TCP is not necessarily optimal for
request-response) nor in the implementation (particularly when some
servers implement access control and/or logging in a way that means
the server does an DNS lookup and/or RFC 931 ident check before
responding. Slow, slow, slow.) CGI is certainly not designed for
speed. But I fail to see how any of this is relevant; these are
merely quirks of some existing implementations. Which back-end is
used is not part of the protcol. (And how did HTTP get involved
anyway?)
> Guess I am saying that the Z39.50 protocol does nothing to make it
>slow, EXCEPT having to do an init, so a minimum of 2 round trips.
>Plus our (Z39.50 IR type environments) are by definition where
>individual record fetches from large corpuses had better be fast.
Some concern, but I wouldn't call it major, about init issues. It has
other implications; Z39.50 presumably could not function via T/TCP,
while presumably whois++ could, for instance. IMHO quite important is
how much code/time/effort it takes on the client end to understand and
implement the protocol, though.
-- Marc VanHeyningen <http://www.cs.indiana.edu/hyplan/mvanheyn.html>