From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/7747 Path: main.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.gnus.general Subject: Re: Another POP question Date: 28 Aug 1996 08:13:31 +0200 Message-ID: References: <6azq68ixrr.fsf@mutt.piper.hamline.edu> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035148018 8389 80.91.224.250 (20 Oct 2002 21:06:58 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:06:58 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.7.5/8.6.9) with SMTP id OAA28518 for ; Wed, 28 Aug 1996 14:25:59 -0700 Original-Received: from ylfing.ifi.uio.no (ylfing.ifi.uio.no [129.240.94.25]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 28 Aug 1996 22:11:48 +0200 Original-Received: (from larsi@localhost) by ylfing.ifi.uio.no ; Wed, 28 Aug 1996 22:11:47 +0200 Original-To: ding@ifi.uio.no In-Reply-To: Sudish Joseph's message of 15 Jun 1996 13:44:36 -0400 Original-Lines: 68 X-Mailer: Red Gnus v0.18/Emacs 19.29 X-Face: &w!^oO~dS|}-P0~ge{$c!h\ writes: > Why not change the division of labor so that the backends only get > unsplittable mail for a specific group; let GNUS itself call the > appropriate backends to get mail from spools mentioned in > nnmail-spool-file (um, gnus-message-sources, see below). > > Currently, the distinction between groups and backends isn't very > clear--backends rely upon the existence of groups using that backend > to be called to fetch mail. Consider IMAP, it can provide both > splittable mail and unsplittable mail. It'd be nice if splittable > mail was fetched and split w/o the user referencing a group using the > nnimap backend. All that should be needed is for the imap default > drop to be added to nnmail-spool-file (with a tag that specifies which > backend is responsible for that spool). Well, there is just a single backend entry point for scanning new mail `nn*-request-scan'. It can be called with a group name as a parameter or nil. If the GROUP parameter is supplied, the backend will try to find group-specific spool files in addition to any global spool files. If no GROUP parameter is supplied, *all* spool files will be snarfed. So the backends do no rely on that function being called with a GROUP parameter to get mail for that group. > Part of the problem here is that all backends aren't equal in the eyes > of GNUS--nntp is more equal that all the rest. Replace nnmail-spool-file > with gnus-message-sources (yuck, you'll think up a better name). > gnus-message-sources would contain information on -all- central > spools, including nntp. For e.g.: > '((nntp . "some.server") (mail . "/var/spool/mail/me") > (pop . "popspec") (imap . "server+mailbox")) > > The user-level interface to all the get-new-news stuff boils down to > just two functions, currently: gnus-group-get-new-news (this is the > place where nntp seems more equal :) There is no `scan' function for nntp/nnspool, so I don't quite follow you here... > and > gnus-group-get-new-news-this-group (which actually does a lot more > than it's name might suggest :). Change what they do as follows: > > Add gnus-group-get-central-new-news, whose -only- purpose is to get news > from sources in gnus-message-sources. > > Add gnus-group-get-all-new-news and tie it to `g'; it is expected to > refresh all groups, would call gnus-group-get-new-central-news once > and then call gnus-group-get-new-news-this-group once per group. > > gnus-group-get-new-news-this-group would do just that--get news for > the -single- group passed as it's argument. I.e., all it'd do is call > the appropriate nn*-retrieve-headers methods for spools specified in > the group params--no looking at gnus-message-sources, ever. `nn*-retrieve-headers' is never called as a response to `M-g'... Anyways, even an `M-g' has to look at all central spools -- there might be mail for the `M-g'd group in those as well as the group-specific spool. -- "Yes. The journey through the human heart would have to wait until some other time."