Re: spam*.el and ifile-gnus.el?

[Arnd Kohrs <kohrs@castify.net>]

    Jeremy> Now that I think about this, this is probably a major
    Jeremy> problem with using ifile and imap together: one of the main
    Jeremy> points using imap is not downloading the entire message
    Jeremy> before you really want it.  I'll bet gnus only downloads the
    Jeremy> headers for splitting.  To use client-side ifile, gnus will
    Jeremy> have to download entire messages (or at least all the text
    Jeremy> parts), which will probably have significant performance
    Jeremy> impact when you're on a slow connection.  When I surface for
    Jeremy> air in a week or two, I'll maybe look into implementing this
    Jeremy> as an option, and see how much people grouse about
    Jeremy> performance impact.


Well, this is the trade-off of using IMAP.  On the one hand it's a
relief that you store your mails somewhere on the net accessible and
save, and on the other hand you can't do nifty stuff such as nnir and
ifile.  I am about to re-migrate from nnml to imap.

However, before I start, I would like to raise two questions:

First, is it not so that during splitting for moving a mail from the imap-inbox
to the imap-destination-folder, the mail is in its text-entirety copied to
emacs and than stored on the imap-destination-folder?  So there would be
hardly any performance loss if all mails are downloaded in their
text-entirety assuming that most(all) mails get moved anyway to another
folder?  

Second, would ifile make sense on headers only, for spam decisions ?

Cheers,

Arnd.