<dd><a HREF="wais://quake.think.com/INFO" INDEX=1>search</a>
<a HREF="wais://quake.think.com/directory-of-servers.src">describe</a>
Careful, representing WAIS servers is tricky. In the gopher world,
the wais .src files are totally hidden from the client, and the links
look just like any other index
Name=Search journalism periodicals
Type=7
Port=70
Path=waissrc:/.wais/journalism.periodicals.src
Host=dewey.lib.ncsu.edu
Whereas in the W3 world the equivalent information would be like
Type=wais
Port=3041
Host=julian.uwo.ca
Path=journalism.periodicals
(e.g) href=wais://julian.uwo.ca:3041/journalism.periodicals?
Which is "better"? Well, you win and you lose. The Gopher approach
binds the gateway tightly to the WAIS server, so there's really no way
to see where the service "really" is, and in particular no way to make
sure that a query to a local service doesn't rebound off some machine
a long ways away. The WWW approach (currently) rebounds everything
off of Switzerland - is anyone else running a WWW_to_WAIS gateway? -
but it leaves open the option to invoke a local WAIS engine.
What happens if (say) the journalism folks at the University of
Western Ontario decide to move their server? Presumably they update
the directory of servers entry; those sites with gopher-based links
pick up a copy of the new .src file, and other servers with links
don't have to do anything special to make an update. But those with
WWW links embedded somewhere in their document need to update them
(bad).
I've thought there might be some use to have the common construct
search the directory of servers for "journalism", then
search all the sources you get back from that for "watergate"
all nailed down into one reference link and one operation. I do that
kind of search all the time and it's just not fair that it takes
multiple steps.
Edward Vielmetti, vice president for research, Msen Inc. [email protected]
Msen Inc., 628 Brooks, Ann Arbor MI 48103 +1 313 998 GLOB