Stephen Isard wrote in <[email protected]>: |It turns out that using on-main-loop-tick to check whether it is time to |renew the auth token doesn't cover the case where you spend a long time |writing a message in the external editor. You come back from the editor |to find that imap has timed out and there is no open folder.
Yes. The main loop ticks whenever a mailx command can be entered. |Since I have defined an account for logging in with oauth, I should be |able to give the command |account oauth |to reconnect. However, I find that I have to issue the command twice. |The first time, I just get a message that there is no open folder. Well there is an old account that is now bogus. That is one of the problem with setting inbox aka folder to an IMAP account. This software never got this right, Stephen, it needs the I/O and MIME layer rewrite to get over all these problems. |Is there some way of trapping the imap disconnection error to trigger a |new 'account oauth'? I see code snippets involving 'trap' in the man |page, but no entry for it in the list of commands. No. I _could_ add a hook in v14.10 that could be sprung in the -keepalive- machinery, but that is in a signal handler, since that is driven by ALARM yet. That is the problem with this software... One should always have a non-blocking event loop that only sleeps sitting on select(2) (now *poll, kevent, or what), waiting for events to happen. Everything else is grazy. If that is no good, you need to separate UI and machinery, i think Rob Pike did so first with the sam text editor in the early 80s. With OAuth and its hm user location tracking capabilities, at least for many maybe the majority, that primitive way that Heirloom unfortunately followed for at least mailx (the doctools are a different thing, as far as i know). Yes how often i said this, i should have thrown it away, take the signal-clean minimal OpenBSD variant, and then just take over what is necessary. We would be at a completely different level. My fault. I never overtook maintainership of a wreck (that has had some great ideas). I would normally suggest driving a cron job that then creates shared credentials to be used by many programs, with S-nail only picking up the latest when necessary. I mean i _could_ hack some concurrent loop in for v14.10 to drive this mess. In fact i rather hammered against a wall two years ago, because of all this, OAUTH with its HTTP[123] / JSON / TIMEOUT mess. Very user unfriendly, almost fascist. Is it. You have even seen the web interfaces these giant companies throw upon you. I always said Kerberos / kinit is much nicer. The timeout problem is a bit easier, at least. The renewal is a lot so. So for now there is _nothing_ you can do. But driving an external thing, via cron, or a simple backgrounded job. It seems to me you _could_ use the shell (`!') command within an account to create a backgrounded thing, and on-account-cleanup to kill it. This, however, does not help with refreshing the credentials within s-nail, within the open connection, of course. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
