On Fri, 27 Oct 2017 01:33:37 +0200 Paul Vixie <paul@redbarn.org> wrote:
Paul Vixie writes:
i was thinking of this: https://en.wikipedia.org/wiki/Push-IMAP
by which means my GUI imap client gets new mail notifications pushed to
it, so that it does not have to poll.
Looks like Push-IMAP was not included in any rfc. But a
client can issue IDLE command and get notified when changes
occur.
the top of thread shows a prediction of likely performance impact from
opening and closing an imap session every time an mh command starts or
stops. i'm arguing against that, because state is necessary in order to
Agreed. My plan for a separate server (or agent) hasn't changed.
receive push notifications, and so to me, the reason to keep one long
lived imap connection open is more important than the performance we
could achieve without doing so.
I haven't relied on email notification for decades. I just use
"inc" when I want to read/respond to email!
sadly, i can already think of non-imap-related reasons why mh needs an
agent of this kind. i think i'm infected with non-unix thinking. ouch.
Not sure what you mean. Unix has daemons!
yes but i was envisioning an nmh-agent that abstracted all operations on
mh objects that would otherwise require locking -- not just keeping an
imap connection open for various mh commands to re-use. bad vixie.
Can't avoid locking completely. New mail may be arriving and
messages being distributed to various folders while you are
running a command.
What I am doing is more than keeping an imap connection open
but not quite just handing over each MH commands to the agent.
An example. Consider
refile $(pick ...) +foo
The pick part is easy. Assuming all the messages pick looks at
are locally cached, we can just use the standard pick (ignore
for a moment the idea of doing a pick on the server).
But refile is implies doing the following (in some sequence):
- linked the message files into +foo
- back up refiled message files by renaming them to their
"comma" names
- send an IMAP command to the server to effect the change.
- update MHID<->UID map in +foo once the server tells us
the new UIDs
- delete some mappings from inbox's MHID<->UID
- We must do this safely so we need a way to complete the
operation in case the connection drops or if we are in a
disconnected state.
This is complicated but doable. But there are some
semantic mismatches which are harder to get right.
1. IMAP MOVE extension beahves slightly differently from HM
refile. After moving a message to a new mailbox it EXPUNGES
it from the old mailbox. MH keeps a backup copy for refile.
2. MH keeps just one backup of a given numbered message while
in IMAP each message has a unique UID so multiple messages
(which may have been numbered the same in the MH world) can
exist in deleted state.
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers