> I've heard all of the naysayer arguments before, but really, it wouldn't
> be _that_ hard. Well, okay, I can see some features being lost, but
> most of the stuff would just sort of fall out once you wrote the
> glue for the backend functions.
Here are some thoughts about IMAP support in nmh. Wherever you see "should",
read it as "Shantonu thinks it should":
1) Backward compatibility: a new, theoretical version of nmh that uses
nmh should be smart enough to use old storage formats if they
already exist. If we implement a new storage backend, it should
be used only if the user starts using advanced features (like
IMAP) that require it. Upgrade and downgrade should be simple.
2) Multiple access points: Since IMAP is based on the idea of checking
mail from multiple locations/clients, nmh should be at *least*
smart enough to do the opposite, which is to check multiple
mail boxes at the same time from the same account. Currently,
this support is fairly kludgy, and half depends on compile-time
options, and half on command-line flags. nmh should be able
to check the local mail spool and IMAP without changing any
conf files, and the syntax should be straightforward (maybe
something like aliases so that "inc home" would get my IMAP
mail like "inc IMAP:ssen:[EMAIL PROTECTED]:INBOX")
3) Cache Messages: Should nmh actually download files to cache messages
locally? Caching obviously has performance advantages for big files
and files that are accessed repeatedly. However, there are
big wins if nmh just sits as a front-end to an IMAP connection,
and doesn't not store local files for IMAP accounts. We wouldn't
have to make many big changes - in fact, the big things would
be hooks into scan and show to look over the network rather
than locally. Also, there would never be any synchronization
problems with the server, since everything is done on the server.
Oh, refile could also be modified to move across IMAP folders.
That being said, I think local caches are the more "nmh-y"
thing to do, and would allow users to have more control over their
individual emails.
4) Role of `inc': In parallel with 3) is what the role of inc would be.
Would it just download an index of new (or unread, depending
on implementation) messages? Alternatively, would it download
a completely new index to make sure it's completely in sync?
Instead, it might not use the advanced IMAP features and just
use the server like a POP machine, and download all the new
messages and display a regular scan after it's done.
As a third option, it could download an index for immediate
user feedback, and then fork into the background and start
downloading messages. If the user requests a particular email
via show, the daemon collector would drop it's current transfer
and make a new request just for that message. If we don't cache
messages, we don't need to worry about this.
The forking thing is messy and contrary to nmh's style, but it's
what I would want as a user: Immediate feedback of new messages,
and then a return to the prompt so that I can decide what to
to next, with minimal delay.
5) Message integrity: If we decide to cache, how do we decide a cached
message is the same as one on the server? Matching subject lines?
Hopefully not. Do IMAP servers have builtin methods for this?
Maybe some hidden headers? Maybe using Message IDs? MD5 (we
already have code for this for using APOP authentication)? Even
if we use something clever like Message IDs, what if the local
copy is modified? Do we consider them equivalent even in their
non-equivalence (MD5 would come in here). If we can't establish
equivalence without downloading the entire message to read
the Message ID or calculate an MD5 sum, we're in trouble, because
there goes any benefit of caching.
6) Refiling: What if a user refiles a message? Does it get immediately
updated in the IMAP server, or does it wait for the next `inc',
which is a sort of synchronization step. Dynamic refiling will
incur natural delays to bring up the connection and then
take it down again. A persistent connection to the IMAP server
would speed things up, but is not the "nmh-y" thing to do.
What if the message is refiled to another server, or just to a
local mailbox? Is it then deleted and expunged from the original
server? Again, immediately, or at the next inc?
7) Server changes: If the messages on the server changed (for example, you
delete some spam while checking your mail from the office), does
the local copy of that message get deleted during the next inc?
That seems a little voodoo-ish, but is definitely the "IMAP"
thing to do.
8) Sortm effects: Would a change in local ordering affect anything on
the server? Maybe, maybe not. At the least, a lot of work
will have to happen to match up messages, especially if there
are concurrent message renumbering and deletions on the server.
9) Subfolders!: IMAP supports subfolders. Should we? What would the
notation and data representation be? Any backward-compatibility
problems? Speaking of which, how would local caches be stored?
In a folder called "IMAP:[EMAIL PROTECTED]"? Yuck. Auxiliary
files to keep track of mappings?
10) Authentication: We should leave hooks in for varying authentication
schemes so we don't need to make lots of changes later. Things
that come to mind include IMAP over SSL. Hopefully, the authentication
would be a simple switch based on command-line flags.
Are these valid challenges? I think it would definitely be neat, but
will take a lot of effort (depending on what level of support and
integration we achieve/try to achieve).
Shantonu
