> > 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.
>
> When designing such a generic interface, you may however happen to
> redesign large parts of what IMAP does.
I know this phenomenon: you think you can make life easier for
yourself by putting an extra module between your program and the
external interface, but when you try to work out the details you find
that the interface to your extra module is just as bad as the original
interface ...
Brendan Cully and I were wondering whether there might be some sort of
role for a program that sits between the MUA and the mail server,
though. Such a program might, for example:
- convert POP3 to IMAP
- protect the MUA from broken network connections
- use a cache for the benefit of MUAs that don't have their own cache
- use a cache so that several MUAs can share the same cache
(e.g. browsing while composing with mutt - you need two of them)
- protect a buggy server from a buggy MUA and vice versa
I haven't thought about it very much yet, so it might be totally
pointless. However, it might also be quite easy to implement using
c-client, particularly since similar things have been done before.
It's the conversion from POP3 to IMAP that is most relevant here. You
can imagine what sort of thing the separate program could do. For
example, the connection goes down, it reconnects, the server doesn't
have UIDs, so it asks for the length of each message, finds a message
with the same length as the one the MUA is asking for, grabs the
headers, does a check-sum to make sure it really is the right message,
then downloads the message, and all the time the MUA things it's
dealing with a reliable IMAP connection. Could be cool.
Edmund
