Ken Hornstein wrote:
I have mail stored on an IMAP server. I think it's perfectly
reasonable that I should be able to do "scan +IMAP:inbox" (or
however you want to indicate that a particular folder is on an IMAP
server; I
Oliver Kiddle <okiddle(_at_)yahoo(_dot_)co(_dot_)uk> wrote:
Why not extend that to +mbox:inbox for mbox folders?
Ugh. This syntax is not generic or transparent and diverges to how MH
currently works. A command-line switch or a configuration file would
be more appropriate if we are going to support multiple email
storage/access formats. I certainly believe that we should provide
the ability to specify the location of the graft folder for IMAP
access. This *will* require additional configuration file commands
and/or an additional configuration file to map local cache folders to
the backend storage, which is much cleaner than trying to change the
meaning of the folder UI.
Seriously, though, perhaps you could consider extending msh to
support IMAP. At least in msh, users don't expect their scripts to
work.
Good point. However, mh commands should be able to provide cached
messages in a manner compatible with current mh paradigms. mhpath,
for example, may report the message lives at /tmp/42987hjklj16h or
~/mail/folder/3. The interface is already proven to work well. If
you need to access an IMAP hosted message for annotation, editing,
viewing, then the mh commands should provide a cached copy for these
operations and synchronize (push) the message when the changes are
complete.
You may need to add commands to synchronize local changes to email
messages with their backend storage, i.e. "mhcache {push|pull|sync}".
Integrating IMAP breaks with the original concepts behind MH. And,
like Robert, I have many scripts used in conjunction with MH.
Without similar IMAP support in these, MH doing IMAP would be of
limited use to me.
Unless IMAP support is crafted in such a way where you can still use
these scripts. Imagine the use of two additional tools and one
configuration extension. mhagent for saving credentials and possibly
keeping persistent client-server connections open and mhcache for
maintaining synchronous copies of the message in the local filesystem.
Neither would have to operate continuously in the background, but
having a daemon function would speed up access.
The last is the ability to graft folders into the path without using
symlinks or other filesystem tricks, specifying the graft location and
how to access the file in a configuration file. For example, a
Maildir folder exists in ~/Maildir/folder. Being able to graft that
in to the MH interface might involve editing .mh_profile to have:
# Recognized as +folderpath
graft-maildir-folderpath: actualpath
# Recognized as +folderpath2 and 3
graft-imap-folderpath2: imaps://username(_at_)password:hostname/INBOX
graft-imap-folderpath3: imaps://username(_at_)password:hostname/mail/folderpath3
It should be entirely possible to do without breaking current MH
design principles. The ability to synchronize local Maildir/MH files
with an IMAP server is provided in a python2.3 program called
offlineimap by John Goerzen. I've tried to use it before, but had
some tough to debug issues with duplicate and missing messages.
Rather than dig into it, I simply continue to use fetchmail/procmail
on my local workstation. He uses a clever trick of annotating each
message with a unique identifier header to help track individual
messages. It's something the person implementing IMAP support should
look in to.
As a point of interest, kmail uses a kioslave (a KDE specific
virtual filesystem) for accessing mail. I think you can use imap://
URLs in konqueror to access this.
Yes, plenty of prior art to help us out here.
--
Chad Walstrom <chewie(_at_)wookimus(_dot_)net>
http://www.wookimus.net/
assert(expired(knowledge)); /* core dump */
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers