Re: [Nmh-workers] IMAP/nmh, again

[Paul Vixie]

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 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