Re: Some Comments

[Simon Josefsson <jas@pdc.kth.se>]

Mats Lidell <Mats.Lidell@contactor.se> writes:

> Simon> Good. I've started collecting success-stories.
> 
> Please add:

Do you know which server you're using?  If unsure, try 'telnet
mail.server 143' and look at what it says (use ". logout" to logout).

> Simon> Perhaps it would be faster if we could byte-compile it
> Simon> too... :-)
> 
> What is the problem with byte-compiling? I tried it and got problems
> with opening the server.

I get the same problem. I haven't cared enough to look into this but
it's on the todo list.

> >> 3) I've asked this before but... I should be able to set up split
> >> rules so that mail pulled from INBOX will be refiled into new IMAP
> >> folders (and corresponding gnus groups) automatically, right?
> 
> Related. How come we need nnimap-split-rule when there is
> nnmail-split-methods already available?

nnimap isn't a nnmail backend.

This is somewhat confusing, I know. I'll try to shred some lights on
this matter (a more Gnus knowledgable person will certainly object,
but I hope this isn't all that wrong).

Splitting isn't done by Gnus. It's done by the mail backend. For the
user, that is of course the same thing but at a implementation level
there is a difference.

Nnml/nnfolder/etc are quite similair, they get mail from one source (a
spool file, POP server, or whatever) and they process the mail and put
it in files on local storage. 

Since this procedure (and other procedures as well, nnml/nnfolder/etc
are very similair) was about the same in all nnml/nnfolder/etc
backends, this functionality where separated into nnmail.

To be able to use the existing nnmail splitting stuff, nnimap had to
fetch all articles in the INBOX to a file, delete the articles on the
server, and hand over the file to nnmail. This is very slow compared
to using COPY+DELETE on the IMAP server. It's also against the nature
of IMAP to do such a thing.

(Ok, the real reason is that I'm lazy -- I don't know the nnmail
splitting stuff that well and wanted to get something working for my
own needs right away. I felt safer with the idea of just COPYing
articles around on the server than removing them from the server,
storing them in some file on local storage and them put them back on
the server in the right fashion)

> Q: Is there some problems with the expire funtionality. (As I get it
> it will be implemented later.) Delete and move of articles seemes to
> work already and what more do we need to start use expiering?

Write the code.  I've begun experimenting with some ways of doing this
-- IMAP lets you search for articles using many search criterias, we
could expire on a user definable search criteria (normally 'read AND
older than x days' or something).

My IMAP folders are growing every day (40MB last time I checked) so
I'd better get around to this soon. :-)

/s