Bakul Shah wrote:
On Fri, 27 Oct 2017 00:41:58 +0200 Paul Vixie<paul@redbarn.org> wrote:
Paul Vixie writes:
there's a think in imap called "push", which is part of why i keep
Not 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-IMAP
by 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
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers