Gnus development mailing list
 help / color / mirror / Atom feed
* Shouldn't agentised servers be switched offline in unplugged mode?
@ 2007-09-08 15:11 Elias Oltmanns
  2007-09-16 22:37 ` Canonical server names and the false assumption in g-s-named-server (was: Shouldn't agentised servers be switched offline in unplugged mode?) Elias Oltmanns
  0 siblings, 1 reply; 3+ messages in thread
From: Elias Oltmanns @ 2007-09-08 15:11 UTC (permalink / raw)
  To: ding

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?

Regards,

Elias




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Canonical server names and the false assumption in g-s-named-server (was: Shouldn't agentised servers be switched offline in unplugged mode?)
  2007-09-08 15:11 Shouldn't agentised servers be switched offline in unplugged mode? Elias Oltmanns
@ 2007-09-16 22:37 ` Elias Oltmanns
  2007-11-09 13:15   ` Canonical server names and the false assumption in g-s-named-server Elias Oltmanns
  0 siblings, 1 reply; 3+ messages in thread
From: Elias Oltmanns @ 2007-09-16 22:37 UTC (permalink / raw)
  To: ding

[-- 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)

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Canonical server names and the false assumption in g-s-named-server
  2007-09-16 22:37 ` Canonical server names and the false assumption in g-s-named-server (was: Shouldn't agentised servers be switched offline in unplugged mode?) Elias Oltmanns
@ 2007-11-09 13:15   ` Elias Oltmanns
  0 siblings, 0 replies; 3+ messages in thread
From: Elias Oltmanns @ 2007-11-09 13:15 UTC (permalink / raw)
  To: ding

Elias Oltmanns <eo@nebensachen.de> wrote:
[...]
> 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.

As for the ChangeLog entry, I'm not quite sure in what format to provide
it to make it easier for you to import. Anyway, here it goes:

* gnus.el (gnus-method-to-server): Add an optional parameter so the
caller can indicate whether the cache should be disregarded for this
call.  This way the result of the call is reproducible at all times and
can be considered a canonical server name for the supplied method.
(gnus-agent-method-p): Canonicalize server names by pushing their method
through (gnus-method-to-server) using the newly added no-cache
parameter.

* gnus-srvr.el (gnus-server-insert-server-line): Use the new no-cache
parameter of gnus-method-to-server for the gnus-named-server property.


Regards,

Elias




^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2007-11-09 13:15 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-09-08 15:11 Shouldn't agentised servers be switched offline in unplugged mode? Elias Oltmanns
2007-09-16 22:37 ` Canonical server names and the false assumption in g-s-named-server (was: Shouldn't agentised servers be switched offline in unplugged mode?) Elias Oltmanns
2007-11-09 13:15   ` Canonical server names and the false assumption in g-s-named-server Elias Oltmanns

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).