Re: Another POP question

Re: Another POP question

[Lars Magne Ingebrigtsen]

[Redirected from gnu.emacs.gnus.]

Sudish Joseph <sudish@mindspring.com> 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."