home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / alt / gopher / 1096 < prev    next >
Encoding:
Text File  |  1992-07-27  |  3.0 KB  |  80 lines
  1. Newsgroups: alt.gopher
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!usc!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!sifon!news
  3. From: peterd@bunyip.com (Peter Deutsch)
  4. Subject: Re: index for all of gopherspace
  5. Message-ID: <1992Jul28.001835.8426@sifon.cc.mcgill.ca>
  6. Sender: news@sifon.cc.mcgill.ca
  7. Nntp-Posting-Host: expresso.cc.mcgill.ca
  8. Organization: McGill University
  9. References: <1992Jul27.180509.27470@mercury.unt.edu>
  10. Distribution: na
  11. Date: Tue, 28 Jul 1992 00:18:35 GMT
  12. Lines: 66
  13.  
  14. In article <1992Jul27.180509.27470@mercury.unt.edu>  
  15. billy@sol.acs.unt.edu (Billy Barron - VAX/UNIX Systems Manager) writes:
  16. > daniel@nstn.ns.ca (Daniel MacKay) writes:
  17. > 
  18. > >Now, the WAIS thang works because all the people who run WAISs, have  
  19. sent
  20. > >in to the mother of all WAISs, an abstract for each database they've
  21. > >published.  
  22. > >
  23. > Not all.  I've found quite a few WAISs that are NOT in the master  
  24. directory.
  25. > This also is the biggest problem with WAIS.  The directory is flat  
  26. and getting
  27. > too big.
  28.  
  29. I submit that the problem is that neither WAIS nor Gopher are an
  30. ideal tool with which to build a distributed Yellow Pages service. 
  31. Gopher does interactive browsing well, while WAIS does large text 
  32. indexing well. What you need is a service that does Yellow Pages well, 
  33. which is both accessible from either service (or as an adjuct to it) 
  34. and is able to keep an up-to-date view of the world.
  35.  
  36. > >Here's the problem I'm trying to solve: I know somewhere in  
  37. gopherspace
  38. > >there's a really good recipe database.  But where is it?
  39. > >
  40. > I agree this is a BIG problem.  I was going to bring it up at the  
  41. Gopher
  42. > Developer's Conference in a couple of weeks and see what could be  
  43. worked
  44. > out.
  45. > 
  46. > >You send a query to the meta-database server, and it returns a
  47. > >list of databases.  You pick one [or several- but we can't do this  
  48. without
  49. > >overhauling the client] of those, and your client sends a search off  
  50. to
  51. > >them.
  52. > >Now, why couldn't we do this with gopher?
  53. >
  54. > This could be done.  Actually, I don't really care to make this a  
  55. "user"
  56. > feature.  It would involve some major coding and maybe a protocol  
  57. change.
  58. > Just something us sysadmins use to figure out where we would like to  
  59. place
  60. > links to.
  61.  
  62. I don't see Yellow Pages as fitting into the Gopher paradigm as such.
  63. It seems that all you want is to ensure that the index of services is 
  64. available _through_ the Gopher clients. This seems like an ideal case
  65. for another gateway function, similar to the one that was recently
  66. discussed for reaching WHOIS servers (which are after all, the White
  67. Pages equivalent of a services listing).
  68.  
  69. Even if our particular hammer is not the right tool to hit this one
  70. with (and I obviously think it is) I would caution against trying to
  71. make every tool do everything. In this case, a well-defined and 
  72. publicised gateway seems to make more sense here(BTW, I would make the 
  73. same arguement for White Pages services. I  definitely think the 
  74. "gateway to WHOIS" approach is the way to go, here, rather than trying 
  75. to extend the Gopher protocol to handle user record searches).
  76.  
  77.  
  78.  
  79.                 - peterd
  80.