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 <[EMAIL PROTECTED]> 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://[EMAIL PROTECTED]:hostname/INBOX graft-imap-folderpath3: imaps://[EMAIL PROTECTED]: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 <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers