>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.
I, for one, have never advocated using IMAP as the only message store
availble for nmh. My thinking is very simple: nmh is a collection
of tools for accessing mailboxes. There's no reason I shouldn't be
able to use the same tools for accessing mailboxes that live on
an IMAP server.
>3) Cache Messages: Should nmh actually download files to cache messages
> locally?
"no".
>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?
I think "inc" should be relegated to simply display headers of
messages that have the IMAP \Recent flag, and not do anything else.
> 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.
Since most IMAP servers also implement POP servers, I'm not sure
this is worth bothering.
>6) Refiling: What if a user refiles a message? Does it get immediately
> updated in the IMAP server,
"yes".
>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.
_if_ you consider IMAP over SSL "secure", which I personally don't.
There's already support in nmh today for using the Cyrus SASL library
for different authentication mechanisms. Using that seems to be the
right thing to do (since nearly all of the IMAP servers are going in
that direction).
--Ken
