home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / bit / listserv / cwisl / 1140 < prev    next >
Encoding:
Text File  |  1992-11-15  |  3.1 KB  |  64 lines
  1. Newsgroups: bit.listserv.cwis-l
  2. Path: sparky!uunet!think.com!sdd.hp.com!ux1.cso.uiuc.edu!news.cso.uiuc.edu!uxa.cso.uiuc.edu!bau50671
  3. From: ullmer@uiuc.edu (Brygg Ullmer)
  4. Subject: Re: Central Management / Desktop Gopher (Universe)
  5. References: <CWIS-L%92111514443821@WUVMD.WUSTL.EDU>
  6. Message-ID: <BxsDoz.5s3@news.cso.uiuc.edu>
  7. Originator: bau50671@uxa.cso.uiuc.edu
  8. Sender: usenet@news.cso.uiuc.edu (Net Noise owner)
  9. Reply-To: ullmer@uiuc.edu
  10. Organization: University of Illinois at Urbana
  11. Date: Mon, 16 Nov 1992 02:02:58 GMT
  12. Lines: 50
  13.  
  14. Steve Cavrak <SJC@UVMVM.BITNET> writes:
  15.  
  16. >On Fri, 13 Nov 1992 04:40:12 EST Shyela Aberman said:
  17. >    As someone pointed out, this gets more complicated because of its
  18. >    nature. If the system is decentralized, management becomes that
  19. >    much harder. What if I turn my machine off every night? The data
  20. >    I have on it becomes unavailable to the rest of the universe. Thus,
  21. >    for now, centralized information servers seem to still have a
  22. >    definite place in CWIS's.
  23.  
  24. >What we'll see, I think, is a "spreading" of information.  Something that
  25. >probably closely mirrors the paper information systems we're used to.
  26.  
  27. In many cases, distributed redundancy is one of the most
  28. powerful tools for dealing with distributed information.  For 
  29. instance, any given execution of "archie" is likely to 
  30. return dozens of locations where the same resource
  31. or various versions of the same resource are available.  In the
  32. case of Gopher and other distributed information systems,
  33. one of the key features necessary to seamlessly build upon this 
  34. redundancy is the Universal Document Identifier.  Hopefully, 
  35. these identifiers will offer easy handles on resource versions
  36. so that redundant sources of information can be effectively 
  37. coordinated.
  38.  
  39. Concerning the point regarding machines turned off at night:  with
  40. decentralized systems, data is often serviced on the 
  41. local networks from a machine which *isn't* turned off.  Mainframes,
  42. Unix workstations, and many other similar machines generally
  43. aren't turned off, either; however, your point is well taken,
  44. and I agree that the coordination of information hosted on 
  45. personal systems is a point which will have to be dealt with.
  46.  
  47. In terms of Gopher and distributed systems, I've operated for nearly
  48. half a year the Gopher service at the Univ. of South Carolina Dept.
  49. of Mathematics, upon which the vast majority of information is
  50. distributed across the net (access to many, many gigabytes is linked
  51. in, while fewer than 10 megabytes are stored locally).  Downtime
  52. of linked machines has indeed been a significant problem, particularly
  53. in cases where the remote sites only store links to other remote sites
  54. (so while the actual source of information may be up, the Gopher service
  55. can't find its way to the site because the link file is not available).
  56. Intelligent caching would be a real plus here, and is a solution I
  57. hope to implement in the "Personal Gopher" (with personally configurable
  58. information spaces) I'm currently developing.  Here again, though,
  59. redundancy is the key feature I hope to exploit for more constant
  60. uptime of resources.
  61.  
  62. Brygg Ullmer (ullmer@uiuc.edu)
  63.  
  64.