Path: utzoo!dciem!nrcaer!scs!spl1!laidbak!att!pacbell!ames!pasteur!ucbvax!hplabs!hp-pcd!uoregon!dboyes From: dboyes@uoregon.uoregon.edu (David Boyes) Newsgroups: comp.os.vms Subject: Re: digesting info-vax Message-ID: <2145@uoregon.uoregon.edu> Date: 4 Jun 88 05:25:40 GMT Article-I.D.: uoregon.2145 References: <8804201644.AA17997@gpu.utcs.toronto.edu> <2071@uoregon.uoregon.edu> <362@mipseast.mips.COM> Reply-To: dboyes@drizzle.UUCP (David Boyes) Organization: University of Oregon, Computer Science, Eugene OR Lines: 70 In article <362@mipseast.mips.COM> rogerk@mipseast.mips.COM (Roger B.A. Klorese) writes: >In article <2071@uoregon.uoregon.edu> dboyes@drizzle.UUCP (David Boyes) writes: >>[my comment about digesting reducing the number of incorrect or duplicate answers] >*NO.* The point of MODERATING is to reduce the naieve, duplicate or just >plain wrong answers. Ok. I can accept this as a reasonable consequence of moderation as well as digesting. However, if you simply have a moderator, that moderator (in my mind) becomes responsible for ensuring that the information allowed to be posted is accurate to the best of his or her ability. Digesting the list (as I would like to do it) would collect instances of each different answer and package them in a weekly form without any guarantee of accuracy -- you pick it; if it works for you, fine. If not, then contact the poster. >One thing has nothing to do with the other. The moderator of a non-digest >list merely edits each message and sends the acceptable ones on to ^^^^^^^^^^ How do you define this? I certainly don't have all types of hardware supported on Vaxes to test each answer. How can you tell which are "acceptable" or not? >>Digesting a mailing list also makes putting the >>information into a database a LOT easier, as digests are usually >>edited into a standardized format and have most of the unnecessary >>header lines and delivery information removed. >...but it makes reading by an individual without a database or an >undigestifying tool ridiculous. If you're so hot on writing a tool to >load a database, surely you can figure out how to deal with standard >headings, which to keep, which to discard, etc. Let's be serious, OK? Estimate that your average Internet mail message passes through 2 or more hosts before delivery; hosts on other networks get even more. Do you *really* need all those Received: headers? If not, why waste the bandwidth to transmit them all over the civilized universe? I have messages in my mailbox right now that have 30+ header lines -- it's silly to transmit all that stuff for every message, especially when it's the 40th repeat of the same answer. As far as not having a database or a undigestifying tool, that seems to me to point directly at some serious deficiencies in the available tools for mail handling, not a point against digesting. As I mentioned before, DEC needs to seriously consider documenting the format of mail files in a non-fiche manner. I know that I don't plan on writing anything that depends on information gleaned from the fiche simply because I have a great aversion to rewriting code because someone at DEC decided to "improve" the way something was done. If they put that sort of information into customer-accessible user documentation, then I think we would see much better interfaces than the current VMS mail system. Both the IBM and Unix worlds have done so, and both have a multiplicity of different interfaces and tools to go about communicating electronically -- VMS has only VMS mail (so far as I know) and some expensive third-party products. I'd like to propose an alternative: I'll set up a digest in parallel to this group and we'll see what works better, OK? Comments and suggestions are certainly welcome. >Roger B.A. Klorese >rogerk@mips.COM -- David Boyes | Internet: dboyes@drizzle.cs.uoregon.edu | (503) 686-4394 | BITNET: dboyes@uoregon | DECnet mail addresses -- just say no.