From: Carl Worth <cworth@cworth.org>
To: Thomas Schwinge <thomas@schwinge.name>, notmuch@notmuchmail.org
Subject: Re: notmuch's idea of concurrency / failing an invocation
In-Reply-To: <87fwsetdin.fsf@kepler.schwinge.homeip.net>
References: <87fwsetdin.fsf@kepler.schwinge.homeip.net>
User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.2.1
	(i486-pc-linux-gnu)
Date: Fri, 28 Jan 2011 15:07:18 +1000
Message-ID: <87ipx9obuh.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

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 no=
w.

>   * 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...
>=20
>   * notmuch internally should catch these concurrency cases, and retry,
>     or eventually give up at some point (``notmuch --maximum-wait=3D30s t=
ag
>     [...]''), 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=3D7eCt0=3DNqUiJFrGDcaZ17LOd3qNNqN1-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.

=2DCarl

[*] 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.

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQFNQk8G6JDdNq8qSWgRAjvfAJ4iWVBB4gIHYhBZJl9PXsVU2we2IQCeJudU
Bx7aUVB1ssMkiuc1L8y3nMs=
=6+jO
-----END PGP SIGNATURE-----
--=-=-=--