|
From: | Paul Vixie |
Subject: | Re: [Nmh-workers] IMAP/nmh, again |
Date: | Fri, 27 Oct 2017 01:33:37 +0200 |
User-agent: | Postbox 5.0.20 (Windows/20171012) |
Bakul Shah wrote:
On Fri, 27 Oct 2017 00:41:58 +0200 Paul Vixie<address@hidden> wrote: Paul Vixie writes:there's a think in imap called "push", which is part of why i keepNot sure what you mean. Perhaps you mean having to push locally created messages to the imap server on reconnect? There is nothing specifically called push.
i was thinking of this: https://en.wikipedia.org/wiki/Push-IMAPby which means my GUI imap client gets new mail notifications pushed to it, so that it does not have to poll.
... An imap session is long lasting but can break (e.g. moving your laptop to a different location with a more expensive data access). So yes, offline access is a goal. While this is my current model, this is an experiment and I assume everything I write is throwaway code. For one thing, it is all in Go :-) [So that I can use it from a Raspi running plan9 as well.]
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 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.
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.
-- P Vixie
[Prev in Thread] | Current Thread | [Next in Thread] |