Re: notmuch's idea of concurrency / failing an invocation

Subject: Re: notmuch's idea of concurrency / failing an invocation

Date: Fri, 28 Jan 2011 15:07:18 +1000

To: Thomas Schwinge, notmuch@notmuchmail.org

Cc:

From: Carl Worth


On Thu, 27 Jan 2011 19:20:00 +0100, Thomas Schwinge <thomas@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@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@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@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.
part-000.sig (application/pgp-signature)

Thread: