1 Return-Path: <jrollins@finestructure.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 olra.theworths.org (Postfix) with ESMTP id 834DD4196F2
\r
6 for <notmuch@notmuchmail.org>; Mon, 12 Apr 2010 08:56:10 -0700 (PDT)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5
\r
12 tests=[BAYES_00=-1.9, T_MIME_NO_TEXT=0.01] autolearn=ham
\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 XniUITdiJGi2 for <notmuch@notmuchmail.org>;
\r
16 Mon, 12 Apr 2010 08:56:09 -0700 (PDT)
\r
17 Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7])
\r
18 by olra.theworths.org (Postfix) with ESMTP id 7438B431FC1
\r
19 for <notmuch@notmuchmail.org>; Mon, 12 Apr 2010 08:56:09 -0700 (PDT)
\r
20 Received: from servo.finestructure.net (geco.phys.columbia.edu
\r
22 (user=jgr2110 author=jrollins@finestructure.net mech=PLAIN bits=0)
\r
23 by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o3CFtwMR012780
\r
24 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);
\r
25 Mon, 12 Apr 2010 11:56:01 -0400 (EDT)
\r
26 Received: from jrollins by servo.finestructure.net with local (Exim 4.71)
\r
27 (envelope-from <jrollins@finestructure.net>)
\r
28 id 1O1LzS-0001vW-OV; Mon, 12 Apr 2010 11:55:58 -0400
\r
29 From: Jameson Rollins <jrollins@finestructure.net>
\r
30 To: Michal Sojka <sojkam1@fel.cvut.cz>, Sebastian Spaeth
\r
31 <Sebastian@SSpaeth.de>, Anthony Towns <aj@erisian.com.au>, notmuch
\r
32 <notmuch@notmuchmail.org>
\r
33 Subject: Re: [PATCH] notmuch new --new-tags=tags...
\r
34 In-Reply-To: <87633wbt9f.fsf@steelpick.2x.cz>
\r
35 References: <n2x87b3a4191004100803z9d4c4c2bp52f5cf0d7b712362@mail.gmail.com>
\r
36 <871velp0be.fsf@SSpaeth.de> <87y6gseval.fsf@servo.finestructure.net>
\r
37 <87633wbt9f.fsf@steelpick.2x.cz>
\r
38 Date: Mon, 12 Apr 2010 11:55:55 -0400
\r
39 Message-ID: <87ljcsekc4.fsf@servo.finestructure.net>
\r
41 Content-Type: multipart/signed; boundary="=-=-=";
\r
42 micalg=pgp-sha256; protocol="application/pgp-signature"
\r
43 X-No-Spam-Score: Local
\r
44 X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7
\r
45 X-BeenThere: notmuch@notmuchmail.org
\r
46 X-Mailman-Version: 2.1.13
\r
48 List-Id: "Use and development of the notmuch mail system."
\r
49 <notmuch.notmuchmail.org>
\r
50 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
51 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
52 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
53 List-Post: <mailto:notmuch@notmuchmail.org>
\r
54 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
55 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
56 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
57 X-List-Received-Date: Mon, 12 Apr 2010 15:56:10 -0000
\r
61 On Mon, 12 Apr 2010 17:11:24 +0200, Michal Sojka <sojkam1@fel.cvut.cz> wrote:
\r
62 > In my mailstore abstraction patches, I suppose that tags for new
\r
63 > messages are derived in some way from mailstore. The idea is, that once
\r
64 > we have a mail store which can store tags (e.g. git-based mails store),
\r
65 > the tags will be assigned on delivery by tools like procmail and notmuch
\r
66 > will only index that tags for faster searching. The problem is the it
\r
67 > will take some time to implement all of this and we want this
\r
68 > functionality now.
\r
70 This is a big effort, and not one that all notmuch users are really
\r
71 interested in, so I would like to not see it specifically guide notmuch
\r
72 development. There are lots of features that would be nice to have
\r
75 In any event, I wasn't suggesting we drop everything to do this. I was
\r
76 just curious what people thought of this approach.
\r
78 > The problem I see with this approach is, that all notmuch searches are
\r
79 > build around Xapian. A simple implementation of the above would mean
\r
80 > that whenever you add a new message to the database, you would need to
\r
81 > execute a Xapian query to see if the new message matches your rule or
\r
82 > not. This would be, of course, very expensive.
\r
84 This does sound like a potential issue. I definitely don't understand
\r
85 how new messages are added to the database. I was mostly suggesting a
\r
86 syntax for adding tag as new messages are added, though, not that an
\r
87 actual xapian search term. I don't know if they can be decoupled,
\r
93 Content-Type: application/pgp-signature
\r
95 -----BEGIN PGP SIGNATURE-----
\r
96 Version: GnuPG v1.4.10 (GNU/Linux)
\r
98 iQIcBAEBCAAGBQJLw0KLAAoJEO00zqvie6q8XRMP/2iTMPoZSUeLzdREjgcd6VpW
\r
99 DBRvnEObEps0i93Kw3eldtcjL/Mt9PMlIP74Pl/GTkKjPbiQcxkOy4WmzwsODCVh
\r
100 i3AiughJoUEVuLuf5+12o5i0lpfwNNYw5dlGC4ZmLNeiupNqJlB8jbcO50wC39Q7
\r
101 7dlb0sumkZYF0kplWVheF9o/S3c9cLnqeOM4M4btt88HwBo/5A87J4LESUCw73is
\r
102 GChSQrt0XH8Iaab0yf9nwa//2T5zWR6LuJnU1zPlouJw1Yl/OqCqyWoNMJqFT1iB
\r
103 MHPXdmIFVuAktwXMB+ki0wlIjZh1YKzj7zIZWgeZQj/ANIypxfvb4jo4Ui7TfVUX
\r
104 kM6TpcSBVJpLg9dxsYeMhBD2ijQdFYw39tr5XSwAsePEOeMoEFOZgh+G+baR6ZsD
\r
105 o9eOnx0yQ15iEF+wnCUfpWzDBCfNqj+6OVXShfC2+NscpYD7q3zCt1teAWc4yBdc
\r
106 8iw7bVg9BtswaVdrmDfSRWlYEr+pbn5mhJfy3mfiHtx4aPE3sZaFSlwhhDpPkCyN
\r
107 RBeMUuGrOBMDbeWtMeaJSY1NrfDxQJIIZQt3H6zuQ5AECPglyEEneoRkzYRDQW+3
\r
108 zugmcUrlPCNx2DEURu1uMJbDlP53pgJJ+XtCL0LwtZOqI3iGsUxOn8RY4FmJlpOe
\r
109 MoxN1mivip1N1sMnQWzl
\r
111 -----END PGP SIGNATURE-----
\r