avoid clash between multiple mail backends

avoid clash between multiple mail backends

[Kai Großjohann]

As Easter is approaching, and hence Lars' Gnus hacking frenzy, I
thought I'd bring up the multiple mail backends issue.

Right now, if you (add-to-list 'gnus-secondary-select-methods '(nnml
"")) and then (add-to-list 'gnus-secondary-select-methods '(nnfolder
"")), nasty things are wont to happen.  Basically, nnml and nnfolder
try to read the same active file, and each one is mightily confused
about the entries from the other.

WIBNI something were done about this?  What _could_ be done about
this?

kai
-- 
The birch trees fly way too low these days.

Re: avoid clash between multiple mail backends

[Karl Kleinpaste]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> Right now, if you (add-to-list 'gnus-secondary-select-methods '(nnml
> "")) and then (add-to-list 'gnus-secondary-select-methods '(nnfolder
> "")), nasty things are wont to happen...
> WIBNI something were done about this?  What _could_ be done about this?

1. Do away with the idea of a single mail active file, and instead
instantiate active.nnFOO per-method active files.

2. Perform an implicit (setq nnFOO-get-new-mail nil) for the 2nd thru
Nth backends encountered.

For the latter, noting that there are some folks who set their primary
method to a mail backend, it won't be sufficient merely to work with
the 2nd through Nth elements of gnus-secondary-select-methods.  If
gnus-select-method is a mail backend, then _all_ entries of
gnus-secondary-select-methods will have to have -get-new-mail set to
nil.

Re: avoid clash between multiple mail backends

[Kai Großjohann]

Karl Kleinpaste <karl@charcoal.com> writes:

> 2. Perform an implicit (setq nnFOO-get-new-mail nil) for the 2nd thru
> Nth backends encountered.

What is this for?  Currently, the first backend which can get mail,
gets all mail, so there's no mail left for the 2nd thru Nth backend,
anyway.

But probably I've missed something.

kai
-- 
The birch trees fly way too low these days.

Re: avoid clash between multiple mail backends

[David S. Goldberg]

You missed group levels.  I think you're right if someone does a `g'.
But if someone has, say nnfolder groups at level 2 and nnml groups at
level 3 with the intention of getting mail via nnml, then running `2
g' will cause all sorts of confusion.  That's the behavior I remember
getting bit by, anyway.
-- 
Dave Goldberg
Post: The Mitre Corporation\MS K207\202 Burlington Rd.\Bedford, MA 01730
Phone: 781-271-3887
Email: dsg@mitre.org

Re: avoid clash between multiple mail backends

[Kai Großjohann]

dsg@mitre.org (David S. Goldberg) writes:

> You missed group levels.  [...] getting bit [...]

Arf.  Oh my Ghod.

kai
-- 
The birch trees fly way too low these days.

Re: avoid clash between multiple mail backends

[Karl Kleinpaste]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> What is this for?  Currently, the first backend which can get mail,
> gets all mail, so there's no mail left for the 2nd thru Nth backend,
> anyway.

Besides `2 g', there's also `M-g'.  Same problem, different incarnation.

Re: avoid clash between multiple mail backends

[David S. Goldberg]

I have successfully used multiple mail backends, nnml and nnfolder in
particular.  The problem you're running into is that they both default
their active files, *-get-new-mail values etc to the same thing.  By
specifying detailed information in the server definitions within
secondary-select-methods (e.g. {nnml,nnfolder}-directory,
{nnml,nnfolder}-active-file etc) I was able to use both backends
without a hitch.  It suppose it would be nice if each backend were
given different defaults so this work wouldn't be necessary but since
the majority of people only want one backend, I'm not sure it makes
that much difference.
-- 
Dave Goldberg
Post: The Mitre Corporation\MS K207\202 Burlington Rd.\Bedford, MA 01730
Phone: 781-271-3887
Email: dsg@mitre.org

Re: avoid clash between multiple mail backends

[Kai Großjohann]

dsg@mitre.org (David S. Goldberg) writes:

> [...]  It suppose it would be nice if each backend were given
> different defaults so this work wouldn't be necessary but since the
> majority of people only want one backend, I'm not sure it makes that
> much difference.

I have posted too quickly, for which I apologize.  I think I should
explain in more detail.

I'm speaking as Advocate of the Newbies, once again...

It appears that more and more people post on gnu.emacs.gnus who are
trying to use more than one mail backend (for whatever reason).
Subjectively, the frequency of such postings seems to be increasing.
Of course, they don't know what they're doing, and hence they don't
include server parameters, and hence they have problems.

One solution is obvious: let all the backends use different active
files, and maybe even different directories.  This will help new
users.  But it might break things for unsuspecting old users.  Hm.

Let's talk about the active files.  What happens now if you have two
servers using the same active file?  Does that mean that users won't
have two servers with the same active file right now?  Then the active
file default could be changed.

If using one active file for two servers now works (kind of), then a
migration mechanism could look like this: server `nnml:foo' looks if
the active file is specified in the server parameters.  If it is, that
active file is used.  If no active file is specified in the server
parameters, then it looks for a ~/Mail/active file and picks out all
the relevant group entries from that and writes them to
~/Mail/active-nnml:foo and uses that file from now on.

And now let's talk about directories.  What happens if you have an
nnml server and an nnmh server, both looking at the same directory
(~/Mail, say)?  (But not at the same active file.)  Does this mean
that creating an nnml group will make an nnmh group mysteriously
appear?  And vice versa?

kai
-- 
The birch trees fly way too low these days.

Re: avoid clash between multiple mail backends

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> One solution is obvious: let all the backends use different active
> files, and maybe even different directories.  This will help new
> users.  But it might break things for unsuspecting old users.  Hm.

Yup.

> Let's talk about the active files.  What happens now if you have two
> servers using the same active file?

Gnus will get very, very confused.

> Does that mean that users won't have two servers with the same
> active file right now?  Then the active file default could be
> changed.
> 
> If using one active file for two servers now works (kind of), then a
> migration mechanism could look like this: server `nnml:foo' looks if
> the active file is specified in the server parameters.  If it is, that
> active file is used.  If no active file is specified in the server
> parameters, then it looks for a ~/Mail/active file and picks out all
> the relevant group entries from that and writes them to
> ~/Mail/active-nnml:foo and uses that file from now on.

Hm.  Well, that's doable, but I think it may be the wrong approach.

I kinda like those "wizard" thingies that other operating systems
have.  Why shouldn't Emacs have them?  Just imagine -- a wizard for
adding new mail backends to Gnus, that would check all these things,
query the users, and create new virtual servers that have everything
set ut poifectly.

> And now let's talk about directories.  What happens if you have an
> nnml server and an nnmh server, both looking at the same directory
> (~/Mail, say)?  (But not at the same active file.)  Does this mean
> that creating an nnml group will make an nnmh group mysteriously
> appear?  And vice versa?

Yes, but not vice versa, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen