On Fri, 27 Oct 2017 01:33:37 +0200 Paul Vixie <p...@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