SYSRUTH@utorphys.BITNET (04/21/88)
Can you explain to me how digesting is going to reduce the volume of
info-vax? Sure, you might get a smaller *number* of MAIL messages, but
there will be just as many articles in them, and they'll be bundled up
in such a way that VMS MAIL is agonising to get through them - you
can't reread an individual article, you can't delete individual articles
with a single keystroke, you can't save articles individually in some
filing scheme that makes sense (in fact you can't do any of these things
with rn, either).
About 90% of info-vax I don't keep. The 10% I do keep I want in a reasonable
form. I don't want to have to forward the damned digest to myself and
edit out all the bits and pieces I don't want.
As to your question "when is SOMEBODY going to digest info-vax" - I guess
the answer is "when SOMEBODY VOLUNTEERS to do it"!
Well ... ?
Ruth Milner
Systems Manager
University of Toronto Physics
-------dboyes@uoregon.uoregon.edu (David Boyes) (05/26/88)
In article <8804201644.AA17997@gpu.utcs.toronto.edu> SYSRUTH@utorphys.BITNET writes: >Can you explain to me how digesting is going to reduce the volume of >info-vax? Sure. >Sure, you might get a smaller *number* of MAIL messages, but >there will be just as many articles in them, No. The point of digesting is to reduce the naieve, duplicate or just plain wrong answers. 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. >and they'll be bundled up >in such a way that VMS MAIL is agonising to get through them - you >can't reread an individual article, you can't delete individual articles >with a single keystroke, you can't save articles individually in some >filing scheme that makes sense (in fact you can't do any of these things >with rn, either). Sounds to me more like a call for DEC to get on the stick and either 1) publish the format of mailbox files so we can write our own interfaces to it, or 2) write a better mail program. So far, VMS mail has come up short in comparison to most of the other mail programs I've worked with in terms of usability and short learning curve. Who in their right mind associates "extract" with copying a message to a file? Both Rice MAIL for VM/CMS and elm/mush/etc ad nauseaum for Unix boxes seem much more straightforward. >As to your question "when is SOMEBODY going to digest info-vax" - I guess >the answer is "when SOMEBODY VOLUNTEERS to do it"! I hereby do so. Where do I apply? >Ruth Milner >University of Toronto Physics -- David Boyes | Internet: dboyes@drizzle.cs.uoregon.edu | (503) 686-4394 UO Systems | BITNET: 556@OREGON1 | "Reading is like living. The more of it you do, the more sense *everything* makes. It constantly amzes me that they pay me to *read*, of all things.."
rogerk@mips.COM (Roger B.A. Klorese) (05/29/88)
In article <2071@uoregon.uoregon.edu> dboyes@drizzle.UUCP (David Boyes) writes: >No. The point of digesting is to reduce the naieve, duplicate or just >plain wrong answers. *NO.* The point of MODERATING is to reduce the naieve, duplicate or just plain wrong answers. 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 the list, whose recipients can then decide which ones to read or discard by subject, original poster, etc. >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. -- Roger B.A. Klorese MIPS Computer Systems, Inc. {ames,decwrl,prls,pyramid}!mips!rogerk 25 Burlington Mall Rd, Suite 300 rogerk@mips.COM Burlington, MA 01803 I don't think we're in toto any more, Kansas... +1 617 270-0613
dboyes@uoregon.uoregon.edu (David Boyes) (06/04/88)
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.
davidli@umn-cs.cs.umn.edu (Dave Meile) (06/05/88)
In article <2145@uoregon.uoregon.edu> dboyes@drizzle.UUCP (David Boyes) writes: >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. You are, of course, assuming that EVERYONE has already (a) read the question and (b) read the answer. Considering the turnover at most businesses (let alone universities), this is a ridiculous assumption. You could, I suppose, post the "20 most often asked questions and their answers" every month, but there is still the off-hand chance that a new poster _hasn't_ read that particular post this month. >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. Are you willing to write such a tool? Are you willing to distribute such a tool to every VAX site in the world that needs to "undigestify" your digest? If so, then I'm all for setting things up in a digest. If not, then don't gripe about what "DEC should do". AT&T certainly didn't create such tools -- users did. (By the way -- you don't particularly _need_ to do it in mail ... a simple TPU program which worked on an extracted mail file would be enough). Now go out and write one. [Not me, though, since I prefer to read this newsgroup in undigestified format via "NEWS"] >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. You should check out PMDF. The address for getting it has been posted to this newsgroup many times, so I don't really need to repost it. >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. >David Boyes | Internet: dboyes@drizzle.cs.uoregon.edu | (503) 686-4394 > | BITNET: dboyes@uoregon | >DECnet mail addresses -- just say no. Actually, a better suggestion would be to install the VMS NEWS program, and then you wouldn't have any particular problem, as you wouldn't have to read mail echoed from the INFO-VAX mailing list. -- Dave Meile
SNJACOB@LSUVM.BITNET (06/28/88)
What is the "VMS NEWS" program? Is it in the public domain? And if so can I ftp a copy from somewhere? Mike Jacobson Networks Manager System Network Computer Ccenter Louisiana State University Phone: (504)388-1331 ARPAnet: JACOBSON%SNMRJ.SPAN@STAR.STANFORD.EDU BITNET: SNJACOB@LSUVM