a true pop3 backend?

a true pop3 backend?

[Wes hardaker]

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


It would be cool to have a true pop3 backend (nnpop).  What's the difference?

It would actually leave the messages on the pop3 server and would work
similar to the nntp backend...  Get the headers, generate the summary
and download the article when you actually requested it.  Marking
something as expirable would delete it from the server on exit.

Of course, this isn't for the idiot, as they shouldn't leave an
obscene amount of mail on a pop server that couldn't take it.  It's
for those of us that want to read mail in gnus away from our main
~/Mail directory.  I work at home 3-4 days a week, which is where I
keep my real mail.  When I actually go into the office I want to use
gnus and check my mail, possibly respond, but not actually download it
from the server.

Should be easy to implement I think.

Currently I'm using the appended patch against 0.12's pop3.el, which
is ok, but it downloads the entire set of mail multiple times.  Ick.

(I'm submitting this patch for the archives as well, obviously).

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


[-- Attachment #2: Type: text/plain, Size: 1184 bytes --]


Index: pop3.el
===================================================================
RCS file: /home/hardaker/src/cvsroot/qgnus/pop3.el,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 pop3.el
*** pop3.el     1997/10/10 15:51:46     1.1.1.1
--- pop3.el     1997/10/17 20:05:45
***************
*** 66,71 ****
--- 66,74 ----
  (defvar pop3-read-point nil)
  (defvar pop3-debug nil)
  
+ (defvar pop3-delete-incoming t
+   "Delete incoming mail from the pop server after downloading?")
+ 
  (defun pop3-movemail (&optional crashbox)
    "Transfer contents of a maildrop to the specified CRASHBOX."
    (or crashbox (setq crashbox (expand-file-name "~/.crashbox")))
***************
*** 347,354 ****
  
  (defun pop3-dele (process msg)
    "Mark message-id MSG as deleted."
!   (pop3-send-command process (format "DELE %s" msg))
!   (pop3-read-response process))
  
  (defun pop3-noop (process msg)
    "No-operation."
--- 350,358 ----
  
  (defun pop3-dele (process msg)
    "Mark message-id MSG as deleted."
!   (when pop3-delete-incoming
!     (pop3-send-command process (format "DELE %s" msg))
!     (pop3-read-response process)))
  
  (defun pop3-noop (process msg)
    "No-operation."

Re: a true pop3 backend?

[Wes hardaker]

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

Re: a true pop3 backend?

[Wes hardaker]

>>>>> On 21 Oct 1997 22:19:44 -0400, Stainless Steel Rat <ratinox@peorth.gweep.net> said:

Rat> That is because you want a full-blown IMAP client.  I did not
Rat> write a full-blown IMAP client, I wrote a low-level interface
Rat> layer for POP3.

Ok, agreed, IMAP would certainly be better.  Of course, I don't have
an IMAP server (as many other people don't)...

Anyway, I do truely understand your points, and know you are a lot
more knowlegable in thea area than me.  I still disagree, but will
assume you're right.

Cheers,
Wes

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

Current status of nnimap? (Was: a true pop3 backend?)

[Steinar Bang]

>>>>> Stainless Steel Rat <ratinox@peorth.gweep.net>:

> The Post Office Protocols were never intended to be used
> interactively.  They were designed as lightweight, "get mail from a
> mail server to a desktop PeeCee" protocols.  If you want IMAP, use
> IMAP (an IMAP backend is in development; you might want to pound on
> that).

Has there been any work done on this lately? John?

I can't do FTP to naiad.fac.cs.cmu.edu, as indicated in
	<URL:http://www.ccs.neu.edu/software/contrib/gnus/#Q4_13>
I get
	% ftp naiad.fac.cs.cmu.edu
	ftp: connect: Connection refused
	ftp> bye
	% 


- Steinar