9a/023bb451cff3f9d714ff5198daea45e07ba4f3

   1 Return-Path: <dkg@fifthhorseman.net>\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 arlo.cworth.org (Postfix) with ESMTP id CA5266DE00E1\r
   6  for <notmuch@notmuchmail.org>; Mon, 11 Apr 2016 15:41:35 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.02\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[AWL=-0.020]\r
  12  autolearn=disabled\r
  13 Received: from arlo.cworth.org ([127.0.0.1])\r
  14  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15  with ESMTP id ZC2-Sq2unO6R for <notmuch@notmuchmail.org>;\r
  16  Mon, 11 Apr 2016 15:41:27 -0700 (PDT)\r
  17 Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118])\r
  18  by arlo.cworth.org (Postfix) with ESMTP id 4D8846DE00BB\r
  19  for <notmuch@notmuchmail.org>; Mon, 11 Apr 2016 15:41:27 -0700 (PDT)\r
  20 Received: from fifthhorseman.net (unknown [38.109.115.130])\r
  21  by che.mayfirst.org (Postfix) with ESMTPSA id 2DC80F991;\r
  22  Mon, 11 Apr 2016 18:41:25 -0400 (EDT)\r
  23 Received: by fifthhorseman.net (Postfix, from userid 1000)\r
  24  id BB74E1FFD1; Mon, 11 Apr 2016 18:41:24 -0400 (EDT)\r
  25 From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
  26 To: David Bremner <david@tethera.net>, Notmuch Mail <notmuch@notmuchmail.org>\r
  27 Subject: Re: thread merge/split proposal\r
  28 In-Reply-To: <878u0l8uyv.fsf@zancas.localnet>\r
  29 References: <87mvp9uwi4.fsf@alice.fifthhorseman.net>\r
  30  <87k2kdutao.fsf@alice.fifthhorseman.net> <878u0l8uyv.fsf@zancas.localnet>\r
  31 User-Agent: Notmuch/0.21+124~gbf604e9 (http://notmuchmail.org) Emacs/24.5.1\r
  32  (x86_64-pc-linux-gnu)\r
  33 Date: Mon, 11 Apr 2016 18:41:21 -0400\r
  34 Message-ID: <87egabu5ta.fsf@alice.fifthhorseman.net>\r
  35 MIME-Version: 1.0\r
  36 Content-Type: multipart/signed; boundary="=-=-=";\r
  37  micalg=pgp-sha512; protocol="application/pgp-signature"\r
  38 X-BeenThere: notmuch@notmuchmail.org\r
  39 X-Mailman-Version: 2.1.20\r
  40 Precedence: list\r
  41 List-Id: "Use and development of the notmuch mail system."\r
  42  <notmuch.notmuchmail.org>\r
  43 List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
  44  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  45 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
  46 List-Post: <mailto:notmuch@notmuchmail.org>\r
  47 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  48 List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
  49  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  50 X-List-Received-Date: Mon, 11 Apr 2016 22:41:35 -0000\r
  51 \r
  52 --=-=-=\r
  53 Content-Type: text/plain\r
  54 \r
  55 On Sun 2016-04-10 09:16:40 -0400, David Bremner wrote:\r
  56 > Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:\r
  57 >\r
  58 >> for (1) i'd propose that the join operation would be implemented by\r
  59 >> adding a new term type "join", which can be applied to any document.\r
  60 >> Its value is the message-id of a message that *should* be "in-reply-to"\r
  61 >> but wasn't.\r
  62 >\r
  63 > Having "split" terms or equivalently "signed" +-reference terms would\r
  64 > allow more general thread splitting, effectively updating (via a little\r
  65 > journal of additions and deletions) the references data stored in mail\r
  66 > file.\r
  67 \r
  68 I'm not sure what you mean by "signed" here (cryptographically signed?\r
  69 a term named "signed"?  the idea that the term could be either positive\r
  70 or negative?), but i think your proposal is that we could have a\r
  71 "reference" term with a value of "+foo@example.com" or\r
  72 "-foo@example.com", instead of having a "join" term with value\r
  73 "foo@example.com" and a "split" term with value "foo@example.com"\r
  74 \r
  75 I'm not sure i see much of a difference between\r
  76 \r
  77  a) introduce two new term types, "join" and "split", with unsigned\r
  78     values\r
  79 \r
  80 and\r
  81 \r
  82  b) introduce one new term type, "reference" with signed values\r
  83 \r
  84 > The implementation cost could not be that much higher than only\r
  85 > join/unjoin; a bit more work managing the terms attached to a document\r
  86 > to avoid contradictions.\r
  87 \r
  88 right -- and we'd need an understanding of the order in which these\r
  89 terms are applied if multiple possibly-conflicting terms are present.\r
  90 \r
  91 > Both versions probably complicate some peoples syncing solutions.\r
  92 \r
  93 both (a) and (b) complicate syncing solutions, but my original proposal\r
  94 of:\r
  95 \r
  96  c) just introduce a new term type "join" with unsigned value\r
  97 \r
  98 is easy to sync, i think; i was going for the low-hanging fruit, and\r
  99 trying to not let it get caught up on the more-fully-featured\r
 100 arbitrary-split use case, though i understand the appeal of the generic\r
 101 approach.\r
 102 \r
 103 fwiw, i can do a really nasty workaround today to implement "join"\r
 104 between two messages:\r
 105 \r
 106 #### notmuch-join:\r
 107 --------------\r
 108 #!/bin/bash\r
 109 \r
 110 verify_exists() {\r
 111     if ! notmuch search --output=files id:"$1" | grep -q . ; then\r
 112         printf "message-id %s is not in your messages\n" "$1" >&2\r
 113         exit 1\r
 114     fi\r
 115 }\r
 116 \r
 117 verify_exists "$1"\r
 118 verify_exists "$2"\r
 119 \r
 120 jdir=$(notmuch config get database.path)/join\r
 121 mkdir -p "$jdir"\r
 122 z=$(mktemp "$jdir/join.XXXXXX")\r
 123 \r
 124 cat >"$z" <<EOF\r
 125 From: test@example.org\r
 126 Date: $(date -R)\r
 127 Message-Id: <$(uuidgen)@join.example.org>\r
 128 References: <$1>, <$2>\r
 129 Subject: join\r
 130 \r
 131 test\r
 132 EOF\r
 133 notmuch new\r
 134 rm "$z"\r
 135 notmuch new\r
 136 --------------\r
 137 \r
 138 And i note that this change is also not synced across dump/restore.\r
 139 \r
 140 So adding an explicit "join" document term (and figuring out how to\r
 141 represent it in "notmuch dump" and "notmuch restore") would be a strict\r
 142 improvement over the current situation, right?\r
 143 \r
 144         --dkg\r
 145 \r
 146 \r
 147 --=-=-=\r
 148 Content-Type: application/pgp-signature; name="signature.asc"\r
 149 \r
 150 -----BEGIN PGP SIGNATURE-----\r
 151 Version: GnuPG v2\r
 152 \r
 153 iQJ8BAEBCgBmBQJXDCgRXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w\r
 154 ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy\r
 155 NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcK8RoQAI82FInuseffZAQKXaHgU5Gm\r
 156 sRq9qytGeqRp0/AQybpYgol5B9JEcB1LoAwpU3ka3CUy6mt4adeABpwnGLgG2bhR\r
 157 oXcD4aT+uiczA9L1E4mipWBAAD0cVfd69zvcU+yF116Gc2FNzE+eNZJ4M+UAEdGc\r
 158 o4Vl8wQVCCxcU9COrtvRSGY5+Z6kc5w/iKH7jOmLCCZsREVT4RXwks7jqUziep17\r
 159 TJDZB62X0f1ZYvcPGrPEvgvlTfdyi+Pt/WvOPrMen6Q6HDAnzhfsruftCANonvyw\r
 160 ROnXHXt7C0Co6AKcB7y33sACk6+8cMreUh2x9ty8Ih9epp580LVg0NudcYwB4pHa\r
 161 C0Zc233ou9z9hMT02jO+C6fxb37yqQJXb4IMfj3Xk8lXstH09Xt1+1jD6Dmo701e\r
 162 iSLn+DCNymvw+gziJy/lzyuMO2EVdvVjW0Qw0EejOwPIxcTcQJuU5PaR7CxFkZyS\r
 163 XQ8KgZ6kvgyvlaOV3PF51dwhYVF64eZ/LGuysB3IsQZ0DTOrdMF/o0cAumosaUmb\r
 164 OOMJ/3xLa6lCN+mUIvn0HQOu+8SBPodbvb2oWmVbC9zqjpd0yJ4FAKd6xBcVQPm4\r
 165 gMSwPvTW1ATUofDUM1KkGp8HKSbuacxDVZZdD+cOG7PVrsTsy+ubkXWarMIr0xhf\r
 166 hK+B8KNhQgbrUNrN1rBo\r
 167 =Gkgo\r
 168 -----END PGP SIGNATURE-----\r
 169 --=-=-=--\r