Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

agent issues in 5.10.2

0 views
Skip to first unread message

NAGY Andras

unread,
Jul 15, 2003, 3:15:20 PM7/15/03
to
It appears that the list of agentized servers is stored in
News/agent/lib/servers as well as in the variable
gnus-agent-covered-methods in .newsrc.eld. Why this redundancy?

Also, the actual parameters for the agentized servers
(e.g. nntp-port-number et al), which are set in .gnus, are also stored
in the variable gnus-agent-covered-methods in .newsrc.eld (and
sometimes in lib/servers too). Again, why this redundancy?

If something is redundant, one day it will get inconsistent. It
happened to me that after changing a parameter (irrelevant to the
server's identity) of a server in .gnus, it resulted in a new entry
for the same server with the new configuration in lib/servers, in
addition to the previous configuration.

What is the `outgoing counterpart' of the `:plugged t' setting in mail
source specifiers? I.e. how can Gnus be configured to send mail even
if in unplugged state (my MTA does queuing, so Gnus doesn't have to) ?


regards,
Andras


Kevin Greiner

unread,
Jul 15, 2003, 6:46:52 PM7/15/03
to
NAGY Andras <na...@inf.elte.hu> writes:

> It appears that the list of agentized servers is stored in
> News/agent/lib/servers as well as in the variable
> gnus-agent-covered-methods in .newsrc.eld. Why this redundancy?

The agentized servers were first stored in lib/servers then they were
added to .newsrc.eld but lib/servers took precidence. I was starting
to work on merging the two when 5.10 was released so the changes have
been put on hold (They're not even finished right now).

> Also, the actual parameters for the agentized servers
> (e.g. nntp-port-number et al), which are set in .gnus, are also stored
> in the variable gnus-agent-covered-methods in .newsrc.eld (and
> sometimes in lib/servers too). Again, why this redundancy?

That was a mistake. Again, the code to fix this is in the works.

> If something is redundant, one day it will get inconsistent. It
> happened to me that after changing a parameter (irrelevant to the
> server's identity) of a server in .gnus, it resulted in a new entry
> for the same server with the new configuration in lib/servers, in
> addition to the previous configuration.

Right. I've run into it myself. It's quite annoying.

> What is the `outgoing counterpart' of the `:plugged t' setting in mail
> source specifiers? I.e. how can Gnus be configured to send mail even
> if in unplugged state (my MTA does queuing, so Gnus doesn't have to) ?

There isn't one. Several work-arounds exist. I believe that the
following is the simpliest. Simply put it at the end of your gnus
start-up file.

(defun gnus-agent-send-mail ()
(funcall gnus-agent-send-mail-function)
)

Kevin


NAGY Andras

unread,
Jul 17, 2003, 4:56:51 PM7/17/03
to
Thanks for all the answers. I'm glad that the mentioned anomalies are
being fixed. Overriding gnus-agent-send-mail also works fine.

regards,
Andras


0 new messages