I'm a little reluctant to reply to this message since I guess I have a
personal interest in mutt's IMAP support, but what the hell...
On Thursday, 09 December 1999 at 00:54, Kim DeVaughn wrote:
> On Wed, Dec 08, 1999, Thomas Roessler ([EMAIL PROTECTED]) said:
> |
> | On 1999-12-08 01:54:57 -0700, Kim DeVaughn wrote:
> |
> | > Or, if that isn't feasible for some reason, then developing a
> | > stand- alone "fetchimap" program would be the way to go.
> |
> | 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?
because making fetchmail do IMAP and writing an interface for that in
mutt is probably as much work as just supporting IMAP natively. On the
other hand, writing an interface to fetchmail for POP is much more trivial
than incorporating fetchmail's relatively bulletproof support for all the
crazy POP servers out there. There are really 3 things you can do with
POP:
1. list the contents of your POP spool.
2. download your messages. if you're lucky, you can download only parts.
3. delete your messages.
writing an interface for those operations is simple. Now think about the
interface for IMAP. Of course since you don't use IMAP you probably
don't know what it is, except that it's some kind of POP replacement.
But from mutt's point of view, IMAP is completely different. It's a
mailbox driver, like mh or maildir. Since I don't use mh, I might as
well argue that mh should be eliminated from mutt...
> | When designing such a generic interface, you may however happen to
> | redesign large parts of what IMAP does.
>
> 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"). What's good for the goose ...
1. you probably don't have IMAP compiled in to your version of mutt. The
IMAP support is (IMHO ridiculously) #ifdef'd away, to the point where if
you don't --enable-imap, mutt can't even recognise an IMAP-style mailbox
name. So you are talking about "code purity". But IMAP is an MUA
protocol, POP is an MDA protocol. Just as it is "impure" to make mutt
do POP services, it is "impure" for fetchmail to do IMAP (although
convenient). MDAs should do POP, MUAs should do IMAP.
In short, IMAP is *not* "super-POP". It is a completely different
protocol.
2. Regarding the bloat - almost all the IMAP code is just to bring IMAP
to parity with the other mailbox drivers (which it still hasn't
achieved). There is almost nothing in IMAP that isn't just an
implementation of a general mutt feature. You don't see that because the
code for all the other drivers was more-or-less finished before you
started using mutt. Maybe you would have been complaining about Maildir
support (which isn't #ifdef'd like IMAP support is), if you had been.
> 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.
try again, please. 1. IMAP could support that. 2. lots of things
continue to exist in mutt for local folders that aren't in IMAP. That's
part of the reason you are flooded with all these fat, disgusting IMAP
patches.
> Yet *useful*, *often asked for* features like compressed-folder-support
> go wanting, and continue to require "third party" patches for support.
I have no comment about that. I certainly don't think it's some kind of
choice between IMAP and compressed folders which IMAP is winning. Do
you?
> There's more, but I'll probably get flamed enough for the above
> heretical comments ... :-) ...
I just don't think you know enough about IMAP vs POP to make the
arguments you're making. Thomas' point about trying to reimplement IMAP
support in an external program was based on his understanding of the
underlying protocols - if you don't know them, I guess the point is
lost. anyway, --disable-imap and relax.
-Brendan
