home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / softsys / andrew / 1194 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  3.3 KB
  1. Path: sparky!uunet!gatech!darwin.sura.net!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!TRANSARC.COM!Craig_Everhart
  2. From: Craig_Everhart@TRANSARC.COM
  3. Newsgroups: comp.soft-sys.andrew
  4. Subject: Re: "slow networks"
  5. Message-ID: <kebZkqz0Bwwt4e=HEj@transarc.com>
  6. Date: 28 Aug 92 17:02:46 GMT
  7. References: <MebPm_m0ts4j4mfEtI@alw.nih.gov>
  8. Sender: daemon@ucbvax.BERKELEY.EDU
  9. Distribution: world
  10. Organization: The Internet
  11. Lines: 53
  12.  
  13. Well, shucks.  When Bill Cattey proposed jettisoning the message server,
  14. I assumed he was talking about jettisoning the funky message-server/MUA
  15. (mail user agent, e.g. cuis, vuis, messagess) split in favor of some
  16. newer protocol.  Not a bad idea to explore, what with interesting
  17. mailbox-access protocols like IMAP and POP to check out.  Certainly the
  18. MS/MUA split is cumbersome for linked-together MUA applications
  19. (messagesn, cuin, vuin--the normal case); what seemed appropriate for
  20. PC&Mac support in 1985 doesn't make that much sense today.  No surprise
  21. here.
  22.  
  23. I didn't realize that what Bill seemed to be targeting was the whole
  24. AMDS picture.  (Yes, lots of folks worked on making that reliable,
  25. including guys like Mike Kazar making AFS work.)  I just don't see how
  26. Bill's AMDS retrospective critique follows.  Essentially, AMDS follows a
  27. client-server model, piggybacking on top of the AFS client-server model.
  28.  AFS effectively provides a real good name service, allowing clients
  29. anywhere to find the correct server for the desired service.
  30.  
  31. Given that Bill has never really lived with AMDS himself, I'm wondering
  32. how he comes to his conclusions.  Perhaps the tenseness in the message
  33. server (the UI-support component) is the stuff that Bill finds
  34. objectionable.  Indeed, it was largely a matter of taste, whether to put
  35. all that address validation support into the message server.  I happen
  36. to like the support it offers.  In trying to package AMDS+messageserver
  37. up for use at non-andrew.cmu.edu sites, the validation support becomes
  38. something of a nightmare for installers, but we tried to deal with this
  39. by making it reasonable for installers to turn all that stuff off.  And
  40. it really can be helpful when it's in a working installation.  The
  41. problem as I see it is that all the messageserver code to support
  42. address validation is nightmarishly complicated.  Is that what Bill's
  43. complaint is really about?
  44.  
  45. I guess I don't follow Bill's paragraph:
  46. Excerpts from internet.other.info-andrew: 27-Aug-92 Re: "slow networks"
  47. Bill Cattey@Athena.MIT.E (1456*)
  48.  
  49. > The AMDS mail delivery method is fundamentally flawed.  It is bad design
  50. > to require the delivery agent to have to deal with the possibility that
  51. > there are as many delivery agents as there are users all attempting to
  52. > write into a unix file system home directory to copy mail in and update
  53. > status simultaneously.
  54.  
  55. Wish I did follow this statement, so I could form some opinion about it.
  56.  Clearly, in any mail delivery scene, somebody serializes mail
  57. deliveries somewhere.  What's the difference how or when that happens?
  58.  
  59. I wouldn't claim that AMDS is flawless, or that there aren't parts that
  60. should be re-worked or withdrawn.  (Or that the messageserver
  61. name-validation stuff is simple.)  I just don't understand this
  62. criticism--whether it's based on some new religion whose evangels
  63. haven't reached this shore, or what.
  64.  
  65.         Craig
  66.