Gnus development mailing list
 help / color / mirror / Atom feed
From: Kevin Greiner <kgreiner@xpediantsolutions.com>
Subject: Re: Kevin's gnus-open-server changes
Date: Thu, 01 May 2003 19:35:40 -0500	[thread overview]
Message-ID: <uel3iw5gj.fsf@xpediantsolutions.com> (raw)
In-Reply-To: <plop87ptn266bi.fsf@gnu-rox.org>

Xavier Maillard <zedek@gnu-rox.org> writes:

> On  1 mai 2003, Lars Magne Ingebrigtsen wrote:
>
>>  kai.grossjohann@gmx.net (Kai Großjohann) writes:
>>  
>> >  But I understand that there was a reason for Kevin's changes.  So
>> >  what was the reason? 

The thread <86el3lqrel.fsf@sophia.inria.fr> in gnus.ding.

I verified Max's observation by executing (gnus-unplugged) while I had
a physical connection to the net.  The result was that my unagentized
servers still opened their connections.  That appeared to be an error
given my reading of the manual (see below).  Since I had modified
gnus-open-server just a couple of months ago, I concluded that I had
introduced a bug.
  
>>  Gnus' unpluggedness is quite different from what you get if you click
>>  on the "go offline" button in Free Agent or other offline
>>  newsreaders.  There "go offline" means "I now no longer have a
>>  network connections, so just do everything locally".  In Gnus it
>>  means "inhibit the servers that are covered by the Agent from opening
>>  network connections".
>>  
>>  Kevin's changes made Gnus behave more like one might expect, but it's
>>  something that can be hashed out in No Gnus.
>
> I agree with that.

I too.

Now then, the first paragraph of Agent Basics in the manual reads:

  First, let's get some terminology out of the way.

  The Gnus Agent is said to be "unplugged" when you have severed the
  connection to the net (and notified the Agent that this is the case).
  When the connection to the net is up again (and Gnus knows this), the
  Agent is "plugged".

I read this description to mean that a server's state when unplugged
must be either denied or offline as those are the only possible states
when dealing with a connection-based server on an isolated machine.

What I didn't consider were

Should the plugged/unplugged status have any effect on a
connection-less server?  For example, shouldn't the nndoc backend always
have a status of ok?

Should the plugged/unplugged status have any effect on an unagentized
server?  If I'm physically connected, but unplugged, shouldn't the
status of an unagentized nntp server be ok (if the plugged status is
ignored) or denied (if the plugged status applies equally to all
servers)?

From yet another thread, if I have an unagentized (or even agentized)
mail server, should the agent ALWAYS store my messages in the drafts
folder?  It seems that some users have a local MTA so they'd like the
option of sending mail even when unplugged.

I hadn't thought to write down my definition of unplugged but it would
probably have been:

  Gnus is said to be "unplugged" when you have informed Gnus that it
  should close existing, and refuse to open new, connections to the
  net.  Connection-less servers are not affected by the "unplugged"
  status.

  Individual connection-based servers may be configured to ignore the
  "unplugged" status.  These servers will, of course, fail if Gnus is
  both "unplugged" and physically isolated from the net.

  Gnus is said to be "plugged" once it is again permitted to open
  connections.

The middle part hasn't been written as I was honestly trying to
introduce a bug fix rather than an entire new feature.  If it did get
written, I'd probably model it on the plugged keyword already existing
in the mail sources list.

So, those are my jumbled thoughts, I'd like to hear what others have
to think.

Kevin



  reply	other threads:[~2003-05-02  0:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-01 11:16 Kai Großjohann
2003-05-01 11:25 ` Lars Magne Ingebrigtsen
2003-05-01 15:21   ` Xavier Maillard
2003-05-02  0:35     ` Kevin Greiner [this message]
2003-05-02 12:14       ` Kai Großjohann
2003-05-02 16:15         ` Lars Magne Ingebrigtsen
2003-05-03 19:59           ` Kai Großjohann
2003-05-04 16:35             ` Lars Magne Ingebrigtsen
2003-05-05  7:19               ` Kai Großjohann
2003-05-05 14:10                 ` Kevin Greiner
2003-05-03  2:06         ` Harry Putnam
2003-05-02 16:17       ` Lars Magne Ingebrigtsen
2003-05-02 19:43       ` Marco Lonsing

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=uel3iw5gj.fsf@xpediantsolutions.com \
    --to=kgreiner@xpediantsolutions.com \
    /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).