notmuch's idea of concurrency / failing an invocation
Carl Worth
cworth at cworth.org
Thu Jan 27 21:07:18 PST 2011
On Thu, 27 Jan 2011 19:20:00 +0100, Thomas Schwinge <thomas at schwinge.name> wrote:
> Which is the original idea here? Is it that...
There's no original idea yet. It's essentially an unsolved problem right now.
> * each and every client should catch these kinds of errors, and retry,
> or eventually give up at some point, and report the status to the
> user; or is it that...
>
> * notmuch internally should catch these concurrency cases, and retry,
> or eventually give up at some point (``notmuch --maximum-wait=30s tag
> [...]''), and fail as seen above?
Some people have actually already done work solutions in one way or
another. Here are a few of the messages I found in my "outstanding
notmuch mail to read"[*] queue:
James Vasile patched the emacs interface to call notmuch
asynchronously and to repeatedly call it if it fails (he also
wonders if it should have some sort of timeout):
id:"87vddnlxos.wl%james at hackervisions.org"
James also wrote a shell script that repeatedly calls the notmuch
binary as necessary (and he wonders if this retrying should happen
inside notmuch itself):
id:"87pr3sw43a.fsf at hackervisions.org"
"servilio" wrote a new "notmuch repl" command which can accept
notmuch operations expressed in text form on stdin, and then
interpret and execute them. That's a good start on a notmuch daemon:
id:"AANLkTi=7eCt0=NqUiJFrGDcaZ17LOd3qNNqN1-ASwYzr at mail.gmail.com"
I'm not sure yet which approach (or approaches) we want. But I would
love to see some of the limitations described in the messages above
addressed. That would definitely make some of the patches more
acceptable.
-Carl
[*] And yes, my queue really does span a year(!) or so. That's
embarrassing. I'm committed to making progress on this queue and staying
up-to-date with new patches, so I've made a couple of recent changes:
1. I'm now processing the queue largely in reverse-chronological
order. The idea here is that I can stay on top of new posts, while
also making progress on previously-sent items.
This does mean that you can hack my workflow by replying to an old
thread, (and thereby bringing it back to my attention). Please feel
free to do that---ideally by mentioning any new information such as
"these patches are now rebased <here>" or "I've tested these patches
in daily use for X months and they still apply fine to master" or
similar.
2. I've date-limited my saved search for my notmuch queue to show a
small number of messages. This is a cheap psychological hack. If the
number on the queue is too large it makes me hesitant to even look at
it. But with a small number, it's easier to make progress since the
end is apparently in sight.
Of course, once I reduce my date-limited queue to 0, I'll extend the
date back into the past and try to keep working through things.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110128/6bf21b58/attachment-0001.pgp>
More information about the notmuch
mailing list