Re: Decision about Host?

Daniel DuBois writes:
 > > > Now, what happens behind the curtains (between the gateway and the
 > > > origin server) is none of our business.  There is no need for that
 > > > communication to even be HTTP.
 > >
 > >While it seems *possible* to take that position, it just doesn't seem
 > >even slightly *useful*, because in practice what will be running inside
 > >the network will be other HTTP servers, not XYZ servers using some
 > >proprietary protocol.
 > My coworker was working on a HTTP server that was a front end to a bunch of
 > Z39.50-protocol searching library servers.  It's more common than you would
 > think.  Our perceptions are skewed because of our intimate familiarity with
 > HTTP.

My comments were intended to be limited to Gateway <=> HTTP server
communication.  All I was saying is that I would expect such
communication to be in HTTP.  I would similarly expect communication
with a Z39.50 server "behind the scenes" to be done in Z39.50
protocol.  Now, if ScamCo releases a gateway product and an HTTP
server product that want to speak to each other in reverse-polish
Swahili with base-19 floating point Roman Numerals, I don't care, but
I expect people will typically mix and match vendors as usual, and that
therefore the way gateways and HTTP servers talk to each other is not
"behind the scenes" except in an academic and not terribly useful

 > Anyway, I agree with Roy.  If the "gateway" knows the port, that's enough.
 > The "gateway" is soley reponsible for mapping the port & URL to some other
 > information-determining mechanism if it wants to take on that job.  As far
 > as the client is concerned, the "gateway" is the end source of information.
 > The issue is closed dude.  Stick a fork in it.  It's toast.
 > -----
 > Dan DuBois, Software Animal   
 > 		I absolutely do not speak for Spyglass.

I'm unattached to this decision one way or the other.  My only reason
to bring up a scenario that would not be covered by this solution is
that *I'm a programmer* and that's what I do: look for the exception
cases that won't be covered by the design, and *then* decide if those
exception cases are worth complexifying the design over.  Maybe
everyone else here has fully simulated this design decision in their
heads to the extent of realizing what the exception cases are and
deciding that they don't matter, without having to talk about it.

It is incumbent on designers of a protocol to try
to cover the bases as well as possible in advance, so that, for
instance, we don't get into another totally disgusting mess like the
current caching/history situation with HTTP.  It's worth it to put a
lot of work into it up front to avoid an even larger amount of work
(and workarounds) for a much larger number of people later.


Received on Monday, 9 October 1995 10:37:45 UTC