Re: [Nmh-workers] Future directions for nmh

[Paul Vixie]

Lyndon Nerenberg wrote:
> > On Mar 16, 2016, at 4:56 PM, Ken Hornstein<address@hidden>  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