Gnus development mailing list
 help / color / mirror / Atom feed
From: Elias Oltmanns <eo@nebensachen.de>
To: ding@gnus.org
Subject: Canonical server names and the false assumption in g-s-named-server (was: Shouldn't agentised servers be switched offline in unplugged mode?)
Date: Mon, 17 Sep 2007 00:37:10 +0200	[thread overview]
Message-ID: <87ejgytey1.fsf@denkblock.local> (raw)
In-Reply-To: <87zlzxyyxs.fsf@denkblock.local>

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

Elias Oltmanns <eo@nebensachen.de> wrote:
> Hi again,
>
> currently, after I have downloaded articles from a server and switched
> into unplugged operation, aell agentised servers remains open in a
> sense, i.e., when I enter a group served by any of those servers, gnus
> tries to connect to the server and if it succeeds, treats it as any
> other open server. Only if the connection fails, the server is switched
> offline. I wonder whether this really is a desirable behaviour.
> Personally, I clearly prefer gnus to behave "unplugged" as it tells me
> in the mode line. If I really want to open one of those servers, I can
> still do so explicitly in the server buffer. Also, the current behaviour
> should be rather annoying in an dial-on-demand setup. Shouldn't
> gnus-agent-close-connections switch all agentised servers offline?

As it turns out, the problem is a somewhat more subtle one. Mind you, I
still think that it would be a sensible idea to switch agentised servers
offline in gnus-agent-close-connections, if only to make sure that they
show up correctly (that is, with status flag "(offline)") in the server
buffer right after switching to unplugged mode.

However, the behaviour I described in my original mail is due to another
problem. As a matter of fact, gnus currently doesn't reliably recognise
agentised servers, or, more precisely, sometimes a method is improperly
considered not covered by the agent. The problem is this:
gnus-agent-covered-methods, sadly, doesn't store methods but only server
names. Well, this approach requires the notion of a canonical server
name. For that purpose, gnus-server-named-server determines the name of
a server by feeding its method to gnus-method-to-server and so should
gnus-agent-method-p. Unfortunately, there is a flaw in this concept
since gnus-method-to-server consults gnus-server-method-cache and
returns the first entry matching the method. Supposing gnus-server-alist
contains an entry like this:
("provider" nnimap "provider"
 (nnimap-server-address "imap.provider.com")

then gnus-server-method-cache will eventually, depending on the sequence
of events, contain entries like this:
(...
 ("nnimap:provider" nnimap "provider"
  (nnimap-server-address "imap.provider.com")
 ...
 ("provider" nnimap "provider"
  (nnimap-server-address "imap.provider.com")
 ...)

So, the result of gnus-method-to-server is not predictable for any given
method if it is in the cache.

For these reasons I suggest to apply the patch attached below. Actually,
I'd prefer to have gnus-agent-covered-methods store methods rather than
servers, but I suppose that this will introduce more problems with
existing installations upgrading to the next release of gnus.

Regards,

Elias

Applies to current trunk:

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: method-to-server.patch --]
[-- Type: text/x-patch, Size: 2443 bytes --]

Index: lisp/gnus-srvr.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus-srvr.el,v
retrieving revision 7.30
diff -u -r7.30 gnus-srvr.el
--- lisp/gnus-srvr.el	31 Jul 2007 03:58:31 -0000	7.30
+++ lisp/gnus-srvr.el	15 Sep 2007 21:50:01 -0000
@@ -280,7 +280,7 @@
        ;; Insert the text.
        (eval gnus-server-line-format-spec))
      (list 'gnus-server (intern gnus-tmp-name)
-           'gnus-named-server (intern (gnus-method-to-server method))))))
+           'gnus-named-server (intern (gnus-method-to-server method t))))))
 
 (defun gnus-enter-server-buffer ()
   "Set up the server buffer."
Index: lisp/gnus.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus.el,v
retrieving revision 7.69
diff -u -r7.69 gnus.el
--- lisp/gnus.el	13 Sep 2007 22:30:42 -0000	7.69
+++ lisp/gnus.el	15 Sep 2007 21:50:08 -0000
@@ -3518,15 +3518,16 @@
 				   (nth 1 method))))
       method)))
 
-(defsubst gnus-method-to-server (method)
+(defsubst gnus-method-to-server (method &optional nocache)
   (catch 'server-name
     (setq method (or method gnus-select-method))
 
     ;; Perhaps it is already in the cache.
-    (mapc (lambda (name-method)
-	    (if (equal (cdr name-method) method)
-		(throw 'server-name (car name-method))))
-	  gnus-server-method-cache)
+    (unless nocache
+      (mapc (lambda (name-method)
+	      (if (equal (cdr name-method) method)
+		  (throw 'server-name (car name-method))))
+	    gnus-server-method-cache))
 
     (mapc
      (lambda (server-alist)
@@ -4252,14 +4253,16 @@
 
 ;;; Agent functions
 
-(defun gnus-agent-method-p (method)
+(defun gnus-agent-method-p (method-or-server)
   "Say whether METHOD is covered by the agent."
-  (or (eq (car gnus-agent-method-p-cache) method)
-      (setq gnus-agent-method-p-cache
-	    (cons method
-		  (member (if (stringp method)
-			      method
-			    (gnus-method-to-server method)) gnus-agent-covered-methods))))
+  (or (eq (car gnus-agent-method-p-cache) method-or-server)
+      (let* ((method (if (stringp method-or-server)
+			 (gnus-server-to-method method-or-server)
+		       method-or-server))
+	     (server (gnus-method-to-server method t)))
+	(setq gnus-agent-method-p-cache
+	      (cons method-or-server
+		    (member server gnus-agent-covered-methods)))))
   (cdr gnus-agent-method-p-cache))
 
 (defun gnus-online (method)

  reply	other threads:[~2007-09-16 22:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-08 15:11 Shouldn't agentised servers be switched offline in unplugged mode? Elias Oltmanns
2007-09-16 22:37 ` Elias Oltmanns [this message]
2007-11-09 13:15   ` Canonical server names and the false assumption in g-s-named-server Elias Oltmanns

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ejgytey1.fsf@denkblock.local \
    --to=eo@nebensachen.de \
    --cc=ding@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).