home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / mail / uucp / 2647 < prev    next >
Encoding:
Text File  |  1993-01-28  |  4.2 KB  |  88 lines
  1. Newsgroups: comp.mail.uucp
  2. Path: sparky!uunet!europa.eng.gtefsd.com!paladin.american.edu!howland.reston.ans.net!sol.ctr.columbia.edu!The-Star.honeywell.com!umn.edu!csus.edu!netcom.com!tweek
  3. From: tweek@netcom.com (Michael D. Maxfield)
  4. Subject: Re: problems with the UUCP maps--duplicate n
  5. Message-ID: <1993Jan28.060558.21548@netcom.com>
  6. Organization: Netcom Online Communications Services (408-241-9760 login: guest)
  7. References: <1993Jan27.033211.29069@netcom.com> <1993Jan27.173519.5079@til.til.com>
  8. Date: Thu, 28 Jan 1993 06:05:58 GMT
  9. Lines: 77
  10.  
  11. In article <1993Jan27.173519.5079@til.til.com> erik@til.com writes:
  12. >
  13. >So, to summarize, you propose having each system that defines a uucp map
  14. >entry have a mailbox that could be queried for the map entry.  This is
  15. >simple enough to do, but I'm not sure how it improves the situation over
  16. >having the system routinely send its map entry to rutgers via email.
  17.  
  18. Depends if they do the maps at regular intervals.  Each area coordinator,
  19. while having standards to meet, might not always do the maps on a regular
  20. cycle.  When I first sent in my map entry, it took six months for the new
  21. maps to come out.  (I believe it was due to a change in the area  project
  22. coordinator.)  If they don't mind getting 6 entries per site for each
  23. map the put out (read that as 6 month of entries) and they are able to
  24. sort through them to find the most recent, fine.  (I mention the sorting
  25. through them... probably only as a poke at your comment about the UUCP
  26. mapping coord. having to send out messages to each system... of course
  27. automation exists for both of those problems.... no offense meant... it's
  28. just late.)
  29.  
  30.  
  31. >In the cron-based approach, each system defining a uucp map entry would be
  32. >responsible for sending in a new map entry before the old one expired.  The
  33. >Coordinators (sound like a bad 60's Sci Fi movie to you?) could choose this
  34. >expiration period arbitrarily.  If a new map entry doesn't arrive in time,
  35. >the old map entry is declared dead and discarded.
  36.  
  37. I'd say, maybe two or three mapping periods of no entries from a site before
  38. that site is deleted... just in case of any unforseen problems somewhere.
  39.  
  40. >
  41. >In the mailbox-based approach, The Coordinators would have to send an email
  42. >[...]
  43. >The problem I see with this is that it actually appears to *increase*, not
  44. >*decrease* the network traffic, in that for each map update there is an
  45. >email query *and* an emailed map entry.
  46.  
  47. As stated above... depends upon if the maps are done at regular intervals
  48. or not.
  49.  
  50. >
  51. >I don't see how having a cron job sending in the map entry leads to
  52. >confusion when the sysadmin changes over, nor do I see how having the
  53. >mailbox improves that situation.  The cron job is as much of a data trail
  54. >as the mailbox, as far as I can see.  Your comment about the mailbox
  55. >approach being easier to handle on non-Unix systems is well taken, however.
  56.  
  57. OK, You've converted me.  As for a CRON mailing of a pre-prepared site
  58. entry, that should be no problem on ANY uucp system.  The automatic
  59. configuration is a different story, but that does not seem like it needs
  60. to be a requirement in order for the CRON mailing to work.
  61.  
  62. >
  63. >As regards the entire bandwidth argument:
  64. >
  65.  
  66. You know...  here we're talking about uucp...  I just plumb didn't think
  67. straight.   
  68.  
  69. Whatever method comes about... (will it be fixed?)  as long as there is
  70. some KNOWN standard that can be implemented by most (99%?) of the sites
  71. in the project, thats fine with me.
  72.  
  73. If the standard is a monthly CRON job, then a subset of standards could
  74. cover manualy-written-entries, CRON-written-entries, and lest we forget,
  75. the proxy-written-entries:  The entries written by a service provider on
  76. behalf of a subscribing system.  Who would be responsible in a case like
  77. that.  The service provider, or the site manager.  Which site should the
  78. entry come from.  [Yikes,  This would be more of a problem in my proposal
  79. for a polled map than it would for a CRONed map.]
  80.  
  81. Are there any Mapping Project Managers (didn't have to use the SciFi term)
  82. out there with any comments? 
  83.  
  84.        tweek@netcom.com  tweek@tweekco.uucp  WWIVNet 5@5058  4@5056 
  85.           I'd rather get my cable service from the phone company,
  86.                 than my phone service from the cable company.
  87.  
  88.