Gnus development mailing list
 help / color / mirror / Atom feed
From: Wes hardaker <hardaker@calwest.net>
Subject: Re: a true pop3 backend?
Date: 21 Oct 1997 17:02:53 -0700	[thread overview]
Message-ID: <x77mb64qc2.fsf@mail.calwest.net> (raw)
In-Reply-To: Stainless Steel Rat's message of "21 Oct 1997 18:24:12 -0400"

>>>>> On 21 Oct 1997 18:24:12 -0400, Stainless Steel Rat <ratinox@peorth.gweep.net> said:

Rat> The moment the session terminates, everthing the backend knows
Rat> about anything would be rendered utterly useless if any changes
Rat> have occoured to the remote mailbox.

That would be gnus's job...  Similar to the nnweb backend, the server
knows nothing and gnus has to track it itself.

Rat> The Post Office Protocols were never intended to be used
Rat> interactively.

True.  I don't necessarily imply otherwise.  Only gnus needs to have
the summary buffer updated.  You exit the summary buffer, and
re-enter, it dumps the *entire* headers again from the server.  Ugly, true.

Rat> I ask that that patch *NOT* be added to pop3.  pop3 is an
Rat> interface library, not a backend.  If you wish to develop a
Rat> replacement for the pop3-movemail reference implementation please
Rat> do so outside of the library.

Hmm...  That actually suprises me.  That patch didn't do almost
anything other than set up another variable allowing you to not call
the 'DELE' command on the server.  It hardly implements the backend
I'm suggesting.  It simply requires that the messages be left there.
Eudora and other smarter mail readers handling situations like this
(Lars is going to shoot me for even remotely implying Eudora might be
smarter in any way to gnus...) compare the msgid's of the current inbox
with those on the server to determine which to download.  That's where
their state comes in.  If you delete something locally not deleted on
the server, you'll quickly find them back in your inbox again the next
time you download new mail if you have the 'dont-delete-on-server'
setting set.

Anyway, as I previously mentioned, I hardly think this is a decent
interface for checking mail on a permenant basis.  Only a 'remote'
basis, when you are at a computer that you don't want to download the
mail to.

Kinda a like a browser...  Similar to the nnweb interface...  No nnml
message numbers...  Probably shouldn't even be stored in the
.newsrc.eld file, except for the fact that the newsgroup exists (ie,
there is no such thing as a 'read' article).

Wes

-- 
"Ninjas aren't dangerous.  They're more afraid of you than you are of them."


  parent reply	other threads:[~1997-10-22  0:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-10-21 20:58 Wes hardaker
     [not found] ` <x7sotuzreb.fsf@peorth.gweep.net>
1997-10-22  0:02   ` Wes hardaker [this message]
     [not found]     ` <x7lnzmpmin.fsf@peorth.gweep.net>
1997-10-22 15:16       ` Wes hardaker
1997-10-22  5:05   ` Current status of nnimap? (Was: a true pop3 backend?) Steinar Bang

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=x77mb64qc2.fsf@mail.calwest.net \
    --to=hardaker@calwest.net \
    /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).