Lyndon Nerenberg wrote:
On Mar 16, 2016, at 4:56 PM, Ken Hornstein<k...@pobox.com>  wrote:

And I believe
it makes it WORSE; each nmh command starts with a brand-new scan of a
folder, so messages added or removed between commands work out fine.
But a FUSE interface would have no idea when an nmh command is starting
or stopping, so you'd have to do a lot of caching or a new IMAP session
for each file access.

That pretty much nuts down the issue. If you want to play IMAP in
MH,you must become a full-on IMAP client, playing all those locking games.

probably the right thing here is to do what the prayer webmail system does.

http://www-uxsup.csx.cam.ac.uk/~dpc22/prayer/

Persistent Login Sessions:

Uses persistent connections to IMAP server and support servers.
Target folders remain SELECTed: not a simple-minded proxy.
Full caching (including sort/thread cache) for each open folder.
Up to five persistent IMAP connections (typically one or two in use):
INBOX and one other folder
Postponed message folder stream
Preferences stream
Folder transfer stream
Various optimisations/sharing to minimise actual IMAP connections
Directory cache: single round trip to IMAP server for directory listing.
Works well with UW IMAP server (even using Unix format mail folders).
> ...
> Written entirely in C as HTTP to IMAP Gateway. No scripting languages.

prayer is the simplest and faster webmail system i ever found for my family's use while traveling.

i suggest that some of the prayer webmail source code could be bundled into an MH-IMAP superproxy, or that prayer could be refactored to support a restful API that MH could access on localhost.

--
P Vixie

_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Reply via email to