agent issues in 5.10.2

agent issues in 5.10.2

[NAGY Andras]

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

Re: agent issues in 5.10.2

[Xavier Maillard]

[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]

On 15 jui 2003, NAGY Andras uttered the following:

>  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?

Can't help you on that.
  
>  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) ?

I think not every people use a local smtp server. For my part, I am
using one from my network but on a different machine than the one
running Gnus. So it is quite usefull to be able to queue mails when I
am not connected on my network (e.g: in the train).

Concerning the way to send mail even if Gnus is unplugged, you just
need to retrieve the mail in the archive (less than 1 week) and you
will find a patch to achieve your goal.

>  regards,
>  Andras

-- 
http://www.gnusfr.org -- French Gnus user site

Anti-war disclaimer:
	"Bombing for peace is like fucking for virginity"

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: agent issues in 5.10.2

[Kevin Greiner]

NAGY Andras <nagya@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

Re: agent issues in 5.10.2

[NAGY Andras]

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