66/d7e814666b3c7c4f264ddbaa8c4e95a78e5ce4

   1 Return-Path: <cworth@cworth.org>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id F0C7E429E22\r
   6         for <notmuch@notmuchmail.org>; Thu, 27 Jan 2011 21:15:36 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.99\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5\r
  12         tests=[ALL_TRUSTED=-1, T_MIME_NO_TEXT=0.01] autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id ktUYd7PHUB+m; Thu, 27 Jan 2011 21:15:36 -0800 (PST)\r
  16 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  17         by olra.theworths.org (Postfix) with ESMTP id 81E0C429E23;\r
  18         Thu, 27 Jan 2011 21:15:35 -0800 (PST)\r
  19 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  20         id 14F0354C004; Fri, 28 Jan 2011 15:07:19 +1000 (EST)\r
  21 From: Carl Worth <cworth@cworth.org>\r
  22 To: Thomas Schwinge <thomas@schwinge.name>, notmuch@notmuchmail.org\r
  23 Subject: Re: notmuch's idea of concurrency / failing an invocation\r
  24 In-Reply-To: <87fwsetdin.fsf@kepler.schwinge.homeip.net>\r
  25 References: <87fwsetdin.fsf@kepler.schwinge.homeip.net>\r
  26 User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.2.1\r
  27         (i486-pc-linux-gnu)\r
  28 Date: Fri, 28 Jan 2011 15:07:18 +1000\r
  29 Message-ID: <87ipx9obuh.fsf@yoom.home.cworth.org>\r
  30 MIME-Version: 1.0\r
  31 Content-Type: multipart/signed; boundary="=-=-=";\r
  32         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  33 X-BeenThere: notmuch@notmuchmail.org\r
  34 X-Mailman-Version: 2.1.13\r
  35 Precedence: list\r
  36 List-Id: "Use and development of the notmuch mail system."\r
  37         <notmuch.notmuchmail.org>\r
  38 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  39         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  40 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  41 List-Post: <mailto:notmuch@notmuchmail.org>\r
  42 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  43 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  44         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  45 X-List-Received-Date: Fri, 28 Jan 2011 05:15:37 -0000\r
  46 \r
  47 --=-=-=\r
  48 Content-Transfer-Encoding: quoted-printable\r
  49 \r
  50 On Thu, 27 Jan 2011 19:20:00 +0100, Thomas Schwinge <thomas@schwinge.name> =\r
  51 wrote:\r
  52 > Which is the original idea here?  Is it that...\r
  53 \r
  54 There's no original idea yet. It's essentially an unsolved problem right no=\r
  55 w.\r
  56 \r
  57 >   * each and every client should catch these kinds of errors, and retry,\r
  58 >     or eventually give up at some point, and report the status to the\r
  59 >     user; or is it that...\r
  60 >=20\r
  61 >   * notmuch internally should catch these concurrency cases, and retry,\r
  62 >     or eventually give up at some point (``notmuch --maximum-wait=3D30s t=\r
  63 ag\r
  64 >     [...]''), and fail as seen above?\r
  65 \r
  66 Some people have actually already done work solutions in one way or\r
  67 another. Here are a few of the messages I found in my "outstanding\r
  68 notmuch mail to read"[*] queue:\r
  69 \r
  70     James Vasile patched the emacs interface to call notmuch\r
  71     asynchronously and to repeatedly call it if it fails (he also\r
  72     wonders if it should have some sort of timeout):\r
  73 \r
  74         id:"87vddnlxos.wl%james@hackervisions.org"\r
  75 \r
  76     James also wrote a shell script that repeatedly calls the notmuch\r
  77     binary as necessary (and he wonders if this retrying should happen\r
  78     inside notmuch itself):\r
  79 \r
  80         id:"87pr3sw43a.fsf@hackervisions.org"\r
  81 \r
  82 \r
  83     "servilio" wrote a new "notmuch repl" command which can accept\r
  84     notmuch operations expressed in text form on stdin, and then\r
  85     interpret and execute them. That's a good start on a notmuch daemon:\r
  86 \r
  87         id:"AANLkTi=3D7eCt0=3DNqUiJFrGDcaZ17LOd3qNNqN1-ASwYzr@mail.gmail.com"\r
  88 \r
  89 I'm not sure yet which approach (or approaches) we want. But I would\r
  90 love to see some of the limitations described in the messages above\r
  91 addressed. That would definitely make some of the patches more\r
  92 acceptable.\r
  93 \r
  94 =2DCarl\r
  95 \r
  96 [*] And yes, my queue really does span a year(!) or so. That's\r
  97 embarrassing. I'm committed to making progress on this queue and staying\r
  98 up-to-date with new patches, so I've made a couple of recent changes:\r
  99 \r
 100 1. I'm now processing the queue largely in reverse-chronological\r
 101    order. The idea here is that I can stay on top of new posts, while\r
 102    also making progress on previously-sent items.\r
 103 \r
 104    This does mean that you can hack my workflow by replying to an old\r
 105    thread, (and thereby bringing it back to my attention). Please feel\r
 106    free to do that---ideally by mentioning any new information such as\r
 107    "these patches are now rebased <here>" or "I've tested these patches\r
 108    in daily use for X months and they still apply fine to master" or\r
 109    similar.\r
 110 \r
 111 2. I've date-limited my saved search for my notmuch queue to show a\r
 112    small number of messages. This is a cheap psychological hack. If the\r
 113    number on the queue is too large it makes me hesitant to even look at\r
 114    it. But with a small number, it's easier to make progress since the\r
 115    end is apparently in sight.\r
 116 \r
 117    Of course, once I reduce my date-limited queue to 0, I'll extend the\r
 118    date back into the past and try to keep working through things.\r
 119 \r
 120 --=-=-=\r
 121 Content-Type: application/pgp-signature\r
 122 \r
 123 -----BEGIN PGP SIGNATURE-----\r
 124 Version: GnuPG v1.4.10 (GNU/Linux)\r
 125 \r
 126 iD8DBQFNQk8G6JDdNq8qSWgRAjvfAJ4iWVBB4gIHYhBZJl9PXsVU2we2IQCeJudU\r
 127 Bx7aUVB1ssMkiuc1L8y3nMs=\r
 128 =6+jO\r
 129 -----END PGP SIGNATURE-----\r
 130 --=-=-=--\r