Re: [PATCH 9/9] add has: query prefix to search for specific properties
[notmuch-archives.git] / 88 / 0a0a955a98120bda755d1d6a1e494d89abbb4e
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 BD1D8431FC0;\r
6         Wed, 16 Dec 2009 10:15:49 -0800 (PST)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 Received: from olra.theworths.org ([127.0.0.1])\r
9         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
10         with ESMTP id n3eOjXbaFTN3; Wed, 16 Dec 2009 10:15:48 -0800 (PST)\r
11 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
12         by olra.theworths.org (Postfix) with ESMTP id A3BAD431FAE;\r
13         Wed, 16 Dec 2009 10:15:48 -0800 (PST)\r
14 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
15         id 309AF254306; Tue, 15 Dec 2009 16:36:05 -0800 (PST)\r
16 From: Carl Worth <cworth@cworth.org>\r
17 To: David Bremner <bremner@unb.ca>, notmuch@notmuchmail.org\r
18 In-Reply-To: <874onsszgw.fsf@convex-new.cs.unb.ca>\r
19 References: <874onsszgw.fsf@convex-new.cs.unb.ca>\r
20 Date: Tue, 15 Dec 2009 16:36:04 -0800\r
21 Message-ID: <87ws0n21sb.fsf@yoom.home.cworth.org>\r
22 MIME-Version: 1.0\r
23 Content-Type: multipart/signed; boundary="=-=-=";\r
24         micalg=pgp-sha1; protocol="application/pgp-signature"\r
25 Subject: Re: [notmuch] wish: syncable/immutable threads\r
26 X-BeenThere: notmuch@notmuchmail.org\r
27 X-Mailman-Version: 2.1.12\r
28 Precedence: list\r
29 List-Id: "Use and development of the notmuch mail system."\r
30         <notmuch.notmuchmail.org>\r
31 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
32         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
33 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
34 List-Post: <mailto:notmuch@notmuchmail.org>\r
35 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
36 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
37         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
38 X-List-Received-Date: Wed, 16 Dec 2009 18:15:49 -0000\r
39 \r
40 --=-=-=\r
41 \r
42 On Tue, 15 Dec 2009 17:23:59 -0400, David Bremner <bremner@unb.ca> wrote:\r
43 > I then try to visit these threads on a different machine, but of course\r
44 > that thread id doesn't exist there, since the database was reindexed and\r
45 > tags reimported.\r
46 \r
47 Ah, good point.\r
48 \r
49 I've wanted reproducible thread IDs also for a similar reason. I\r
50 anticipate writing a tool to create HTML versions of the archives of\r
51 mailing lists. In this case I want to have thread IDs in URLs and I want\r
52 those URLs to be persistent even if I re-build the index from scratch.\r
53 (For this case, I'd also like to have small thread IDs, such as\r
54 consecutive integers.)\r
55 \r
56 > I don't know if it is in any way practical, but it would be nice from my\r
57 > point of view if thread id's were a property of the mail collection, or\r
58 > at least it was possible to dump and restore them.\r
59 \r
60 I think it's quite practical. The easiest answer is probably to simply\r
61 include the thread ID in each line of the dump output. And then we\r
62 should ensure that thread IDs as well as tags are accounted for in the\r
63 design of any synchronization mechanism to support multiple notmuch\r
64 databases. One thing to consider is whether we want to continue to have\r
65 any amount of compatibility with the sup dump format\r
66 \r
67 > If this is too much of a corner case, then I suspect I can work around\r
68 > it in the emacs client by calling search twice, first with an id in the\r
69 > thread.\r
70 \r
71 That's almost similar to what sup does, which is to use a message ID of\r
72 a the first message encoutered in a thread as the thread ID. Doing that\r
73 alone doesn't help with the case of rebuilding the index on separate\r
74 machines since it makes the thread ID dependent on the order in which\r
75 messages are processed.\r
76 \r
77 But yes, if you can make your links depend only on message IDs then you\r
78 can get reliable results even before we start including thread IDs in\r
79 the dump output. The result of "notmuch show --entire-thread id:foo" is\r
80 quite similar to the result of "notmuch show thread:bar" (for the\r
81 corresponding thread ID of course). It differs only in the "match"\r
82 field, which is used to determine which messages to open by default.\r
83 \r
84 -Carl\r
85 \r
86 --=-=-=\r
87 Content-Type: application/pgp-signature\r
88 \r
89 -----BEGIN PGP SIGNATURE-----\r
90 Version: GnuPG v1.4.10 (GNU/Linux)\r
91 \r
92 iD8DBQFLKCt16JDdNq8qSWgRAqLUAJ0c2IHmMQqikL8V5ELh9Pog498YfwCfQpKK\r
93 YEGpUhcwWIr19/l8ZSQ6FEA=\r
94 =G/3S\r
95 -----END PGP SIGNATURE-----\r
96 --=-=-=--\r