Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!THUMPER.BELLCORE.COM!nsb From: nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) Newsgroups: comp.soft-sys.andrew Subject: Re: Dear Saint Andrew... Message-ID: Date: 19 Jul 90 19:49:40 GMT References: <0adTPN8B0TlkM4PEF=@zany.EuroPARC.Xerox.COM> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 99 Excerpts from info-andrew: 19-Jul-90 Re: Dear Saint Andrew... Lennart Lovstrand@Xerox. (15952+1) > But wait! If I just look at the operations that are available through > the menu stack (deck?), most of the ones applicable to individual > messages also have its twin in the "marked messages" section. Only the > ones in italic below seems to be solely applicable to either one or the > other (or neither). So it seems to me that one could at least write a > set of substitute functions that would check wether or not any messages > had been marked and then invoked the appropriate single/multi messages > function function instead. Maybe you were thinking about something > else, though? Yeah, the thing is that there are times when the choice isn't obvious. For example, sometimes people mark things as they're reading a folder, planning to deal with them en masse at the end. So they're reading the Nth message, with K marked so far, and they say "delete". Now, do they mean delete this Nth message that I'm reading at the moment, or the K messages that are already marked? > I first tried to track down all the places where a new header was added > to the message and make sure it was added after the From_ line. After > having patched two or three different places with no noticable result, I > finally gave up and made cvtold.c turn the From_ line into a > Return-Path: header instead. [Patch available on request] One thing > puzzled me, though. Std UNIX stores the envelope information in the > From_ line, but where does AMDS put it? Or maybe it doesn't keep any? In the Return-path, I believe. By the way, I'd strongly encourage you to send that patch back to the ITC. > Nope, it's the other way around. The "From" address may be specified by > the UA, and if not authentic, must be supplemented with a "Sender" by > the mail system, indicating the authenticated sender of the message. > See RFC822 section 4.4.1 and 4.4.2. OK, so sue me -- I was talking from memory and had it backwards. The gist of what I was saying remains true, which is that it isn't as simple as just eliminating the code that nukes the From lines -- you also have to add code that does the right thing with a Sender line. I guess that wouldn't really hurt, and would be easily implemented. > Well, I guess this is something up to discussion, but as I see it, the > more I can trust on some underlying functionality to do the job, the > less I need to think about all the possible ways it could go wrong. > This surely is a good thing in 99% of all cases. To make a naive > analogy with TCP and UDP: The very reason for TCP's existence is that > it's (supposedly) reliable, making it possible for the programmer to > largely forget about possible failures on the network. When it comes to > Andrew, there seems to be an awful lot of code there which solely is > concerned with the success or failure of an AFS call. This has the > effect of obscuring the true function of the code and making hard to > understand, especially for someone outside the original development > community. Even if there are many ways something may go wrong in a > distributed FS environment, it seems to me that trying to make the > applications programs compensate to compensate for this would be to > attack the problem on the wrong level. Actually, there is (or used to be, I don't know which) an AFS option that said "don't ever let any FS operations fail -- just wait forever if necessary until you can make them succeed." If that had been the way AFS always behaved, the AMS code would have been much simpler. Unfortunately, that turns out to be NOT the behavior users want when one file server out of twenty goes down... > >From a user's standpoint, I agree that defensive coding is good if it > makes the system more reliable. I only wish that it could have been > confined to just a very few key places. Yeah, it could have been more modular, I'll grant that readily enough. >> Sigh. You can re-sort your own folders by evaluated-Date: header value. > How? (Except for writing my own date parser and copying the messages > from one folder to another and running cui's scavenge.) Use the CUI "reconstruct" command. > Thanks for taking the time to answer it! > And the same goes to all you other people who answered. It's clear to > that you take pride in your creation (and rightly so), but it's even > more encouraging to see that you're open for suggestions and > improvements. It's easy for me to be open-minded, since I'm no longer the one fixing the code... [An Andrew ToolKit view (an animated drawing) was included here, but could not be displayed.] ---------------------------------------------------------------------- [An Andrew ToolKit view (a raster image) was included here, but could not be displayed.] [An Andrew ToolKit view (a raster image) was included here, but could not be displayed.] Nathaniel S. Borenstein Member of Technical Staff, Bell Communications Research Office: Bellcore Room MRE 2A-274, 445 South Street, Morristown, NJ 07962-1910 Work phone: (201) 829-4270 Work FAX: (201) 829-7019 Home: 25 Washington Ave., Morristown, NJ 07960, (201) 993-8586