having IMAP folder names be different would be a Kosmik Lose(tm)
the only reason to do IMAP would be because it's transparent.
Every GUI for IMAP that I've ever seen presents the remote folders in
a section or subfolder representing the IMAP account. This permits
mutiple IMAP accounts and local
I am doing it -- in fact, I have a perl module that does basic scan,
show, refile and rmm. It also supports hierarchical default mime part
display, i.e. if there is a text/plain part, it shows that, if not, it
shows a text/html part, etc. Finally, it supports mime part viewing,
i.e. I can
I want to do IMAP too. I have an idea for design:
1. a .rc file with credentials (i.e. username, password and IMAP server)
2. All mh folders as normal, except if a directory has a .imaprc (or
similar) file in it, then it has no real files -- it is a reference
to an IMAP folder
Is it
On 23 Dec, you wrote:
I want to do IMAP too. I have an idea for design:
If I had a need for IMAP support, I would sooner consider writing a FUSE
module for an IMAP filesystem. It'd have more chance of working with
scripts written around MH because non-MH commands would work.
Short of a grab
Is FUSE platform independant? It seems to be fairly Linux-oriented, but
I may not be digging deep enough. This page
http://fuse.sourceforge.net/wiki/index.php/OperatingSystems doesn't seem
to list many OSes yet, but it may be out of date.
From a user perspective, my approach would be invisible
If I had a need for IMAP support, I would sooner consider writing a FUSE
module for an IMAP filesystem. It'd have more chance of working with
scripts written around MH because non-MH commands would work.
Short of a grab only mode in inc I'd be against cluttering all the nmh
commands with IMAP
