From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/3978 Path: main.gmane.org!not-for-mail From: Sudish Joseph Newsgroups: gmane.emacs.gnus.general Subject: External delivery: Pros and cons Date: 15 Nov 1995 03:01:39 -0500 Organization: The Ohio State University Dept. of Computer and Info. Science Sender: joseph@cis.ohio-state.edu Message-ID: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035144790 28150 80.91.224.250 (20 Oct 2002 20:13:10 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:13:10 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by miranova.com (8.6.11/8.6.9) with ESMTP id BAA20741 for ; Wed, 15 Nov 1995 01:21:29 -0800 Original-Received: from news.cis.ohio-state.edu (news.cis.ohio-state.edu [164.107.8.50]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 15 Nov 1995 09:01:46 +0100 Original-Received: from honsu.cis.ohio-state.edu (honsu.cis.ohio-state.edu [164.107.138.13]) by news.cis.ohio-state.edu (8.6.8.1/8.6.4) with ESMTP id DAA18223 for ; Wed, 15 Nov 1995 03:01:44 -0500 Original-Received: (joseph@localhost) by honsu.cis.ohio-state.edu (8.6.7/8.6.4) id DAA04596; Wed, 15 Nov 1995 03:01:41 -0500 Original-To: The Ding List Original-Lines: 75 Xref: main.gmane.org gmane.emacs.gnus.general:3978 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:3978 Pros: - Much faster startup. Cons: - It is possible to lose mail if you're not careful in setting things up. - Not easy to set up, you'll have to juggle the startup files for both your filtering agent and gnus. Losing mail in this context comes in two flavors. a) You actually lose the message. b) The message itself isn't lost, but the NOV/active file entry gets clobbered, so you might not know you received the message. (Not a problem if you use nnmh instead of nnml.) Avoiding lossage for the two cases: a) Actual lossage of the entire message is possible if you use the copy and move commands from the summary ("B m" "B c"). In this case, gnus generates the new article number on the basis of potentially old information, so it could overwrite a newly delivered message. Solution: Don't move/copy into groups you deliver to. Sounds stupid, yes, but it's not a big pain in practice. It's possible to make this safe using locking, but looks like it'd be a pain to implement. b) The active file getting clobbered is not a big deal, it'll get corrected again by the next mail that arrives for that group. The NOV file can get clobbered in two ways. It's possible for an entry to get deleted due to gnus overwriting a newer version. It's also possible to get your nov entries entered in non-ascending order. Solution: For the active file problem, modify gnus-group-get-new-news-this-group (M-g in the group buffer) to do an nnmh-style lookup for the nnml group. This would make it simple to correct the active file entry. This is also more consistent with how nntp groups are handled (uses the active file for mass lookup/does a GROUP for a -this-group lookup). A better solution is to use locking (see below). For the NOV entry being deleted problem, use locking. Essentially, provide hooks for the user to run whatever locking method they want (procmail users might run `lockfile' off such hooks). Four hooks would suffice: one pre- and post- pair for active file update, another pair for NOV update. The non-ascending NOV file should really be the filters problem...except that doing this isn't efficient for some filters. It's not a problem in mailagent, since only one mailagent is active at any given time; doing a sort from procmail for _every_ message you get is prohibitively expensive--sleeping for earlier articles to be updated leads to the possibility of long queues of processes hanging on one possibly-dead process) It'd be simple enough to get GNUS to read such malformed NOV files properly, but Lars fears that this might cause a slow down. I don't think it'd be that bad. If this is unacceptable, we could have a variable that would let the user select a version of gnus-get-newsgroup-headers-xover that allows unsorted nov files, while leaving the default the way it is. If none of the above are unacceptable, use an external script to sanity check.correct your overviews and active file. Or you could use nnml-generate-nov-databases for this, but it clobbered something or the other the last time I used it. :-) None of the above are very difficult to implement, the only real issue is whether any such code will be put into gnus itself. I'd rather not have _another_ large chunk of code I have to patch into every release I fetch. Besides, sooner or later, people're going to hack their version of GNUS 5.x to do stuff like this...(I will, for one :) -Sudish