On 1999-12-09 00:54:26 -0700, Kim DeVaughn wrote:
>> You are free to write such a program, and you are also free to
>> design a generic interface between mutt and external mailbox
>> backends. Note, however, that just downloading messages into
>> some local folder and using the usual mbox/maildir code is not
>> an option.
> Why not ...? That is exactly what folks using POP3 are being
> told to do with fetchmail. Why the "double standard" for IMAP
> support?
It's not really a "double standard". All you can reasonably do with
POP3 is fetching messages to your local spool. With IMAP, you can,
for instance, store messages in server-side folders, you have
support for (and problems with) concurrent folder updates on the
server, etc.
POP3 is some kind of kluge to get around the "last mile" when the
end user's system doesn't have a full-fledged mail transport system.
With IMAP, no mail folders on a local system are necessary.
> I don't want/use/need IMAP, which is why I am tired of seeing
> mutt get bloated with support for it (in contrast to the stated
> reason for not improving POP3 support, and indeed efforts to
> remove it ... to reduce "bloat").
The point about POP3 support is that fetchmail can do really
everything mutt's own POP3 support gives. However, you won't be
able to put reasonable IMAP support into an external program, unless
maybe you design it as a filesystem kernel module which presents
maildir-style folders to the user. ;-)
(And no, I don't like IMAP or the amount of complexity introduced by
it myself. But then again, IMAP seems to be the general way to go
for on-the-server mail spools...)
> I'm also tired of seeing useful things (such as the recently
> eliminated M-flag) being removed from mutt "because they don't
> work with IMAP" mailboxes. Etc.
Sorry, the M-flag wasn't removed from mutt "because it doesn't work
with IMAP".
--
http://www.guug.de/~roessler/
