home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / bit / listserv / cwisl / 1117 < prev    next >
Encoding:
Text File  |  1992-11-11  |  3.6 KB  |  84 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!stanford.edu!unixhub!fnnews.fnal.gov!overload.lbl.gov!zeus.ieee.org!europa.asd.contel.com!paladin.american.edu!auvm!HUB.UCSB.EDU!COOK
  3. Message-ID: <9211111806.AA14511@bluemoon>
  4. Newsgroups: bit.listserv.cwis-l
  5. Date:         Wed, 11 Nov 1992 10:06:29 PST
  6. Sender:       "Campus-Wide Information Systems" <CWIS-L@WUVMD.BITNET>
  7. From:         "(Steve Cook x4753)" <cook%bluemoon@HUB.UCSB.EDU>
  8. Subject:      Re: Justification for CWIS
  9. Comments: To: "Campus-Wide Information Systems" <CWIS-L@wuvmd.wustl.edu>
  10. Lines: 72
  11.  
  12. >    Date:         Tue, 10 Nov 1992 13:55:56 PST
  13. >    From: "(Steve Cook x4753)" <cook%bluemoon%HUB.UCSB.EDU@wuvmd.wustl.edu>
  14. >    Subject:      Re: Justification for CWIS
  15. >
  16. >    >    But I just wonder how many of the units that might be in a
  17. >    >position to supply cwis-able information--schedules of events, notices of
  18. >    >meetings, whatever--would be in a position to "gopher-ize" that
  19. >    >information themselves. Perhaps someday, but it might be that the way to
  20. >    >package a CWIS right now is as a way-station on the path to a network
  21. >    >where information is exchanged desktop-to-desktop, with little in the way
  22. >    >of "central" information services.
  23. >    >    Good luck.
  24. >    >
  25. >    >--
  26. >    >FROM - Charles Forrest           VOICE  404-727-0137
  27. >    >       Woodruff Library            FAX  404-727-0805
  28. >    >       Emory University         BITNET  libcgf@emoryu1
  29. >    >       Atlanta, GA   30322    INTERNET  libcgf@unix.cc.emory.edu
  30. >
  31. >
  32. >    In fact, this is what a gopher server on the back end of a
  33. >    Macintosh can do today.  So it is possible to publish a local
  34. >    CWIS, and connect to others everywhere with gopher.
  35. >
  36. >    Steve Cook
  37. >    Computing Coordinator
  38. >    College of Letters and Science
  39. >    UC Santa Barbara
  40. >    Santa Barbara,  CA  93106
  41. >    cook@bluemoon.ucsb.edu
  42. >    805 893-4753
  43. >
  44. >Or, to put in a more interesting way, I on my Macintosh Plus (hypothetical,
  45. >as I'm on an SE/30) could connect to, oh, say Tokyo University and peruse
  46. >some of their papers on quantum physics, at the same time searching through
  47. >Harvard's name server (or program of comparable function) for that guy named
  48. >Smith I met last year at the Conference in Boulder, etc.
  49. >
  50. >Sounds kind of like an Apple, Inc. commercial I saw a while ago...all it takes
  51. >is more CWIS's....and more bandwidth.
  52. >
  53. >Shy Aberman
  54. >(litbu741@vader.cc.emory.edu)
  55.  
  56. Ok, so I should also add the fact that this works today on unix
  57. 'desktop-to-desktop' stations, but it's not working this way yet on
  58. PC's.  I do have an experimental SE-20 here as a server, and although
  59. it cannot handle a lot of loading, it is functional for low-demand
  60. sites.  I would like to see a windows gopher server and client
  61. software someday -- this would make the concept more usable on the
  62. pc side of the house.
  63.  
  64. But, there is a basic problem with publishing out of the back end
  65. of a 'desktop system': reliability.  If the information is only available
  66. when the system is on, then few people will use it if they get a
  67. 'cannot reach' message on the first few attempts.  Servers will continue to
  68. be valuable since they tend to be on more often than not.
  69.  
  70. I view the desktop publication capability as one that helps get some
  71. folks over the 'becoming a provider' hump.  Once they are there, and they
  72. understand the mechanics of a CWIS, then I encourage them to move to a
  73. predicatble server, if that's a mac -- fine, but it could be any box.
  74.  
  75. The bottom line to me is that the gopher technology is getting to the
  76. point where there is something for everybody, and that helps getting
  77. the concept up and running.
  78.  
  79. (this is beginning to sound like an add for gopher, would you guess
  80. that I like the software?)
  81.  
  82. Steve
  83. cook@bluemoon.ucsb.edu
  84.