be/47b72916c34213ea34d09f241d23ce1437928b

   1 Return-Path: <bremner@unb.ca>\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 CD3A6429E26\r
   6         for <notmuch@notmuchmail.org>; Sun, 11 Dec 2011 16:12:34 -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: -2.29\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_MED=-2.3, 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 yJgivdcXVG1s for <notmuch@notmuchmail.org>;\r
  16         Sun, 11 Dec 2011 16:12:34 -0800 (PST)\r
  17 Received: from tempo.its.unb.ca (tempo.its.unb.ca [131.202.1.21])\r
  18         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  19         (No client certificate requested)\r
  20         by olra.theworths.org (Postfix) with ESMTPS id B6DE1429E25\r
  21         for <notmuch@notmuchmail.org>; Sun, 11 Dec 2011 16:12:33 -0800 (PST)\r
  22 Received: from zancas.localnet\r
  23         (fctnnbsc36w-156034079193.pppoe-dynamic.High-Speed.nb.bellaliant.net\r
  24         [156.34.79.193]) (authenticated bits=0)\r
  25         by tempo.its.unb.ca (8.13.8/8.13.8) with ESMTP id pBC0CTmA028366\r
  26         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);\r
  27         Sun, 11 Dec 2011 20:12:32 -0400\r
  28 Received: from bremner by zancas.localnet with local (Exim 4.77)\r
  29         (envelope-from <bremner@unb.ca>)\r
  30         id 1RZtVN-00012z-9y; Sun, 11 Dec 2011 20:12:29 -0400\r
  31 From: David Bremner <david@tethera.net>\r
  32 To: Notmuch Mail <notmuch@notmuchmail.org>\r
  33 Subject: Re: experimental logging branch\r
  34 In-Reply-To: <87obvfu6t5.fsf@zancas.localnet>\r
  35 References: <87obvfu6t5.fsf@zancas.localnet>\r
  36 User-Agent: Notmuch/0.10.2+80~g144897e (http://notmuchmail.org) Emacs/23.3.1\r
  37         (x86_64-pc-linux-gnu)\r
  38 Date: Sun, 11 Dec 2011 20:12:13 -0400\r
  39 Message-ID: <87liqik5r6.fsf@zancas.localnet>\r
  40 MIME-Version: 1.0\r
  41 Content-Type: multipart/signed; boundary="=-=-=";\r
  42         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  43 X-BeenThere: notmuch@notmuchmail.org\r
  44 X-Mailman-Version: 2.1.13\r
  45 Precedence: list\r
  46 List-Id: "Use and development of the notmuch mail system."\r
  47         <notmuch.notmuchmail.org>\r
  48 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  49         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  50 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  51 List-Post: <mailto:notmuch@notmuchmail.org>\r
  52 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  53 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  54         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  55 X-List-Received-Date: Mon, 12 Dec 2011 00:12:34 -0000\r
  56 \r
  57 --=-=-=\r
  58 Content-Transfer-Encoding: quoted-printable\r
  59 \r
  60 On Sat, 10 Dec 2011 23:27:02 -0400, David Bremner <david@tethera.net> wrote:\r
  61 > This uses the jlog library (http://labs.omniti.com/labs/jlog)\r
  62 > to atomically log messages in pub-sub model.\r
  63 \r
  64 Some more explanations.=20\r
  65 \r
  66 Part 1: pub-what?\r
  67 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\r
  68 \r
  69  What is pub-sub? Conceptually you can think of\r
  70 it as a set of queues where each "published" message is magically\r
  71 replicated and put in the queue of each "subscriber". Of course in\r
  72 practice one only needs one queue, and to keep track of how far each\r
  73 subscriber has read.  So, we have a queue, and one head pointer per\r
  74 subscriber.  We can discard anything in the queue that all of the\r
  75 subscribers have read past.\r
  76 \r
  77 In jlog this data structure is on disk, which is why it is called\r
  78 "durable". This means there are no sockets to communicate between the\r
  79 publisher (notmuch) and the subscribers (e.g. a proposed tag synching\r
  80 tool, described more below).  The interact via a directory (currently\r
  81 under .notmuch). Because the datastructure on disk is not completely\r
  82 trivial (not that fancy either, but more than a stream of bytes) both\r
  83 writers and readers need to use the jlog library to interact with the\r
  84 queue.  "notmuch log" is one such reader.\r
  85 \r
  86 I'm not that invested in jlog, but I looked around and didn't find any\r
  87 other similar solutions that had some atomicity guarantees without some\r
  88 kind of broker (read yet another daemon running on the machine).=20=20\r
  89 \r
  90 > On this branch you can enable logging of tagging operations by=20\r
  91 >=20\r
  92 >    notmuch config set log.subscribers 'name1;name2;name3'\r
  93 \r
  94 The command "notmuch log" lets one read the queue from the shell.\r
  95 "notmuch log name1" dumps any messages (only the string content; there\r
  96 are timestamps but these are currently ignored) queued for "name1" to\r
  97 stdout. So one can interact with this queue without learning about the\r
  98 jlog api (or more precisely, without copy-pasting the example programs\r
  99 From=20the wiki like I did).\r
 100 \r
 101 Part 2: Ok, but what is it good for?\r
 102 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=\r
 103 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\r
 104 \r
 105 OK, so there is this tool, but why should we bother?  I think tag\r
 106 synchronization is one of the big missing pieces for notmuch (probably\r
 107 because Carl only reads mail on one computer ;) ). There are various\r
 108 hacks, but they are all based on dump/restore.  nmbug only manages to\r
 109 have (mostly) acceptable performance because the query of "tags starting\r
 110 with notmuch::" (done in a hacky way) restricts the output to manageable\r
 111 levels.  I think what we need is a way to to update incrementally, and\r
 112 obvious way to do this for tags is to keep track of additions and\r
 113 deletions, and maintain a "shadow" of the database on disk in some form\r
 114 more amenable to synchronization. This could be a directory/file tree\r
 115 like the initial versions of nmbug, or some slightly fancier thing like\r
 116 the bare git repo used by current versions of nmbug. With the jlog\r
 117 patches to notmuch, one or more scripts could run (in cron, or perhaps\r
 118 using something like inotify) to treat the log of tagging operations as\r
 119 essentially a patch to update the "shadow tag database".  In my case I\r
 120 would probably want two subscribers, one for my whole tag database, and\r
 121 one to update the set published in nmbug.=20=20\r
 122 \r
 123 A more wild idea would be to use the queue to help resolve contention\r
 124 for write access to the Xapian database. Clients would write into a\r
 125 queue, and notmuch would read operations to perform out of the queue. To\r
 126 be honest, I'm not sure this is really better than just having clients\r
 127 use locking and blocking/retrying.=20=20\r
 128 \r
 129 Part 3: Couldn't we do this with hooks?\r
 130 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=\r
 131 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\r
 132 \r
 133 Conceptually, yes. But there are a few things to figure out:\r
 134 \r
 135 1) hooks are a CLI feature, not a library feature. Do we want the\r
 136    library to support something like hooks?\r
 137 \r
 138 2) The cost of an exec per elementary tagging operation is quite high;\r
 139    maybe some kind of batching could help with this.\r
 140 \r
 141 3) Atomicity/locking would need to be dealt with by each script.  For\r
 142    example git update-index, used by nmbug (and git add) will fail if\r
 143    some other operation is in progress. But having a hook block sounds a\r
 144    bit nightmarish.\r
 145 \r
 146 None of this stuff is my area of expertise; maybe some of you have\r
 147 clearer ideas about how this could/should be handled.\r
 148 \r
 149 d\r
 150 \r
 151 \r
 152 \r
 153 \r
 154 \r
 155 \r
 156 --=-=-=\r
 157 Content-Type: application/pgp-signature\r
 158 \r
 159 -----BEGIN PGP SIGNATURE-----\r
 160 Version: GnuPG v1.4.11 (GNU/Linux)\r
 161 \r
 162 iJwEAQECAAYFAk7lRt0ACgkQTiiN/0Um85lGeAP/ZQ2xnfSN4vjJmSElhkIfUvdp\r
 163 WsVW42q/pOPdN3qi4nwYU/1V938BvHToDl+ZQbD2OI2/3wVh/4SEYGrQIJMHz7Ty\r
 164 pw9gYEKv4OV0BqYoVjza0i+BwW4hjiYNvKatyTqkeXmYDxCyKULF6egF9lNS+F1p\r
 165 16naS+96+vqwaSX326E=\r
 166 =eY1q\r
 167 -----END PGP SIGNATURE-----\r
 168 --=-=-=--\r