Re: mail-sources backend specific?

[prj@po.cwru.edu (Paul Jarc)]

kai.grossjohann@gmx.net (Kai Großjohann) wrote:
> Suppose you have this situation:
>
> (setq gnus-secondary-select-methods
>       '((nnml "one" (nnml-mail-sources foo))
>         (nnml "two" (nnml-mail-sources bar))))
>
> Clearly there must be a mechanism that prevents the two settings for
> nnml-mail-sources stomping on each other.

Yes: the nnml backend has the notion of a "current server", and only
one setting is in effect at a time.  nnoo is used to set
nnml-mail-sources, according to the server name ("one" or "two").

> So can't this mechanism be used to also protect mail-sources, instead
> of only nnml-mail-sources?

No, because the mechanism is tied to the backend's notion of its
current server.  If two backends are involved, there are two current
servers, so variables must have different names to avoid interference.

nnmaildir does not use nnoo, and its server parameters are not
prefixed with "nnmaildir-".  It does not use global variables to
represent its server parameters.  So there is no problem here:
(setq gnus-secondary-select-methods
      '((nnmaildir "one" (directory "~/one"))
        (nnmaildir "two" (directory "~/two"))))
This works because nnmaildir does not set "directory" as a global
variable; instead, it looks up the string keyed by the symbol
'directory in the select method.  (Actually, the information in the
select method is copied into a more efficient vector, but that's not
important.  The point is that private, anonymous data structures are
used instead of global variables.)  The same could be made to work
with nnoo-derived backends, but they would not be able to refer to
such parameters as if they were global variables.


paul