Shantonu Sen <[EMAIL PROTECTED]> writes:
> Here are some thoughts about IMAP support in nmh. Wherever you see "should",
> read it as "Shantonu thinks it should":
I don't know enough about IMAP to have any thoughts on some of your points,
but...
> 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")
Yeah, I suspect a lot of people are like me and have external wrapper
scripts (mine are called "check_mail" and "inca" and integrate with xbiff)
that make the multi-mailbox support nicer. I've been wanting to enhance
nmh's native support for this. Not sure if you were implying this or not,
but I don't think inc should always include from all defined mailboxes --
one should be able to include from a single one (or a couple) if desired.
> 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.
If local caching is implemented, ideally it'd be disablable, so people could
optimize for slow or fast network connections.
> 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.
That forking behavior would be very nice. Presumably trying to look at
message that hasn't yet been downloaded would block until it was.
> 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?
Well, nmh already supports subfolders using subdirectory notation, so I
don't see why this should be different for IMAP support.
> 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).
Yeah, your thoughts really make it clear how much potential work is here.
Sounds like most of the issues arise from cache handling, though. Perhaps a
first implementation could do everything live on the IMAP server.
-----------------------------------------------------------------------
Dan Harkless | To prevent SPAM contamination, please
[EMAIL PROTECTED] | do not post this private email address
SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.