home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / alt / galactic / 911 < prev    next >
Encoding:
Internet Message Format  |  1993-01-22  |  3.2 KB
  1. Path: sparky!uunet!spool.mu.edu!agate!doc.ic.ac.uk!uknet!keele!nott-cs!florence.linuxnet!dpg
  2. From: dpg@cs.nott.ac.uk (`Grave' Dave Gymer)
  3. Newsgroups: alt.galactic-guide
  4. Subject: Re: TUG! 2 --> (The Net Guide)
  5. Keywords: TUG admin network gopher irc tcp-ip
  6. Message-ID: <C17KEw.2u6@florence>
  7. Date: 21 Jan 93 14:32:56 GMT
  8. References: <C0x499.2r3@cs.nott.ac.uk> <gavin.727489695@sorokin>
  9. Sender: dpg@cs.nott.ac.uk (Dave `geek' Gymer)
  10. Organization: Association of Slack Producing Geeks
  11. Lines: 59
  12.  
  13. In article <gavin.727489695@sorokin> gavin@sorokin.anu.edu.au (Gavin Longmuir) writes:
  14. >dpg@cs.nott.ac.uk (`Grave' Dave Gymer) writes:
  15. [...]
  16. >This looks like a great idea, but I can see some problems - with a networked
  17. >system and site that runs a server must be able to add new articles to the
  18. >'database' and tell all other servers if has this new information (the info
  19. >should only be transferred if required). Perhaps I'm talking about some kinda
  20. >cross between IRC and the gopher.
  21.  
  22. Well, I as thinking that each server (other than the `root' one) would at some
  23. point in time pull down the index from some other server or set of servers,
  24. see what was new or changed, and then pull down those articles into its local
  25. database.  In making each server responsible for its own database, we also
  26. allow it to set its own policy about when to update stuff; each server could
  27. also refuse to service certain hosts at certain times, thus allowing it to set
  28. a policy on when it will allow other servers to update from its database.
  29.  
  30. The server updating utself then appears to the server being updated from as a
  31. normal client process, simplifying both the protocol and the code.
  32.  
  33. >Given my above idea - there would have to be a new protocol with at least 4
  34. >different request/information formats (packets etc..); one giving the physical
  35. >status of all server links,
  36.  
  37. I don't think this is necessary or even desirable; there's no reason why the
  38. links should be anything other than transitory, created anew for each request
  39. (this is how gopher works).
  40.  
  41. >one for the guides index (I can't any reason why
  42. >there can't be more than one entry for a topic - like dictionaries)
  43.  
  44. Absolutely.
  45.  
  46. >which also
  47. >contains the locations of the entries (the guide should evolve so when a server
  48. >is decommissioned all articles in it's database [which don't exist elsewhere]
  49. >are forgotten by the other servers).
  50.  
  51. Well, I can see two possibilities here:
  52.  
  53. 1. All servers hold all articles.  This is in some repects desirable as it
  54. allows readers to fetch any article required from a relatively local site.
  55.  
  56. 2. As stated earlier, each server could periodically query other servers as to
  57. the articles available, and build index and cross reference lists from the sum
  58. of this information, and use gopher-style links merely to the entry text
  59. itself.
  60.  
  61. [...]
  62. >Just my ideas (but I may just like to work of such a beast!)
  63.  
  64. Well, I sure as hell don't want to have to tackle such a thing alone!  :-)
  65.  
  66. -- Dave
  67. -- 
  68. `Grave' Dave Gymer | ``The only rule in Calvinball is that you can't
  69. 42 St Mary's Park  |   play the same rule twice.'' -- Calvin and Hobbes
  70. Louth, Lincs       |----------------------------------------------------
  71. LN11 0EF, England  |         Warning, Linux fanatic in transit.
  72.