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.     

Reply via email to