[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Future directions for nmh

From: Paul Vixie
Subject: Re: [Nmh-workers] Future directions for nmh
Date: Wed, 16 Mar 2016 18:04:40 -0700
User-agent: Postbox 4.0.8 (Windows/20151105)

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]